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Preface 



The Department of Electrical Engineering-ESAT at the Katholieke Universiteit 
Leuven regularly runs a course on the state of the art and evolution of computer 
security and industrial cryptography. The first course took place in 1983, the 
second in 1989, and since then the course has been a biennial event. 

The course is intended for both researchers and practitioners from industry 
and government. It covers the basic principles as well as the most recent de- 
velopments. Our own interests mean that the course emphasizes cryptography, 
but we also ensure that the most important topics in computer security are 
covered. We try to strike a good balance between basic theory and real-life ap- 
plications, between mathematical background and judicial aspects, and between 
recent technical developments and standardization issues. Perhaps the greatest 
strength of the course is the creation of an environment that enables dialogue 
between people from diverse professions and backgrounds. 

In 1993, we published the formal proceedings of the course in the Lecture 
Notes in Computer Science series (Volume 741). Since the field of cryptography 
has advanced considerably during the interim period, there is a clear need to 
publish a new edition. Since 1993, several excellent textbooks and handbooks 
on cryptology have been published and the need for introductory-level papers 
has decreased. The growth of the main conferences in cryptology (Eurocrypt, 
Crypto, and Asiacrypt) shows that interest in the field is increasing. In addition, 
new conferences have emerged (such as Fast Software Encryption and Informa- 
tion Hiding) which illustrate the expansion of the research. These conferences 
offer ample opportunity to present new research results. However, there is still 
a need for papers presenting an overview of the state of the art in areas that 
are particularly important for applications, or papers introducing novel areas or 
applications. We believe that the authors of this volume have done an excellent 
job in explaining recent developments in a wide range of topics within this excit- 
ing area. We thank them for their considerable efforts. We also acknowledge the 
assistance of all members of our research group COSIC (Computer Security and 
Industrial Cryptography) in the preparation and running of another successful 
course. 

Finally, we would like to dedicate this book to the memory of Rita De Wolf, 
who did an outstanding job in organizing our courses, but who was also a valuable 
friend and colleague. 



Leuven, Belgium 
1998 



B. Preneel and V. Rijmen 
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Trends in the Fight Against Computer-Related 
Delinquency 



Bart De Schutter 

Center for the interaction between law and technology 
Vrije Universiteit Brussel 



1 The Phenomenon 

The grasp of information technology upon almost all societal activities is an 
indisputable and irreversible fact. Transfer of data, information, knowledge or know- 
how has undergone with the technological wave a profound change in its form, speed 
and distance coverage. This mutative effect can certainly be beneficial to society in all 
its components (economic, strategic, intellectual, cultural). 

It seems, however, that the margin between u^ and abuse is rather narrow. Even if 
criminality related to information has always existed, the intervention of the computer 
with its above-mentioned characteristics of time, volume and place, leads to the risk 
of a criminal activity, the nature of which might be different from the more classical 
information crimes. To look into the phenomenon, its size frequency and profile, will 
lead to the necessary conclusion for the need of policies, which may be necessary to 
effectively combat this anti-social behaviour. 

In that exercise one encounters a number of difficulties. A first one concerns 
already the definition of computer delinquency. According to the purpose for which it 
is needed, one can work with a more criminology-oriented definition, describing the 
deviant pattern from the sociological angle, or could need a more precise terminology 
when introducing the illegal act as crime in the penal arena, then requiring precise 
material and moral elements in the definition. Avoiding the multitude - and the 
nuances - of definitions of the expert writers [1], there is much merit in the OECD 
working definition, referring to "any illegal, unethical or unauthorised behaviour 
relating to the automatic processing and/or the transmission of data” [2], since the 
answer to computer criminality is likely not to be limited to an exercise of criminal 
law drafting alone. 

However, the danger of such an extensive "opening definition" is that it allows a 
somewhat overqualification of incidents, in which the computer does not play any 
instrumental role at all. Some demystifying and relativation has to be done to bring 
the phenomenon back into real proportions, avoiding the sensationalism of its media 
coverage. 

Scarcely a day passes without any newspaper-clip on computer-crime or fraud. 
Television picks up the item and visualizes the "hacking" techniques. The difficulty, 
however, is to bring those individual findings into some global figures and clear 
indicators. This seems, often, to be too delicate, if not impossible. 

There is clear reluctance and unwillingness in communication of incidents. Banks, 
insurance companies or any other potential victim are not easily communicative on 
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losses occurred through incidents related to their information system. Image-loss, 
indirect consequences such as the thrust of the customers or the competitive position, 
all push towards secrecy and discretion. The simple anonymous transfer of 
information for statistical purpose to official instances, even international ones, is 
objected to. The interference of judicial authorities is considered as being "counter- 
productive". 

Many of the incidents come in the daylight through indiscretion, erroneous 
behaviour of the criminal himself or when insurance companies oblige the client to do 
so before refunding any loss. Besides, some countries are more communicative than 
others [3]. For sure one can state that figures are incomplete, that guesses should be 
considered with care and that we only know the top of the ice-berg. 

Since several years a considerable number of official bodies or professional circles 
are showing interest in gathering valuable information. All of it should be read with a 
critical eye, since under- or overscoring is likely. Nevertheless, figures are impressive 
and worthwhile to be recalled : SRI mentions 100 million $/year in the U.S., the FBI 
makes two billion dollars out of it [4]. For Europe, an interesting estimate is the one 
of the Association Internationale pour I'Etude de I'Assurance . which comes up with 
six billion dollars loss for Europe already in 1988. A U.K. survey by the Local 
Government Audit Inspectorate led to 80 % of 320 interviewed firms having been 
victim of a computer fraud [5], while in 1985 four major British banks budgeted £ 85 
million against computer frauds. The French CLUSIF reports a yearly amount of 
nearly 11 billion FF of voluntary or accidental damaging of information systems. [6] 

It is not the purpose of this paper to recall the spectacular and classical examples 
such as the Equity-funding [7] or Security Pacific Bank [8], or Memorial Sloan 
Kettering Cancer Institute [9], the French ISOVER Case [10] or the CLODO 
activities [11], or many other [12] not to forget the Internet misbehaviours or 
"cybercrimes" such as pornography, libel or racism [13] but it may be important to 
recall that not all incidents are linked to economic interests as such, but may equally 
concern health, privacy, morality or state strategic survival. 

If the overall size of computer abuses is substantially high, though not full-proof, it 
has also been shown that these totals concern a limited number of victims. 
Concentrating the losses upon few leads to the conclusion that the average gain of 
such crime is a hundred times that of the average classical hold-up, while the average 
time for the discovery of the misbehaviour seems to be counted in years, not in 
months [14]. 

To be added to this picture is the great potential of the transborder dimension of 
information technology, whereby the physical presence of the actors across the border 
is no longer necessary. The internationalization of this criminality adds a new 
dimension to the task of society in reacting against this phenomenon. 

As to the actors themselves, they seem roughly to fall into two major groups: on 
one hand the computer-freaks, the youngsters trying to hack systems for fun, 
competition, challenge; whizkids or wargamers, i.e. "short-pants criminality", not 
necessarily with a clear criminal intent; on the other hand, willful criminality by 
hackers or employees within the system, often highly qualified and technically 
skilled, often acting from within, abusing the hi-tech and jargon oriented "state in the 
state" position of the EDP-sector. 

In conclusion on the characteristics of the phenomenon one can say that 
information systems, whether used for simple data storage or retrieval, word 
processing, business activities, banking, electronic fund transfer, electronic mail. 
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health care, R & D, defense systems, ..., are vulnerahle to attack hy experts or freaks, 
young or old, acting from within or without the area of operation of the machine, with 
results to be estimated with a mutative scale difference, since time, space or volume 
have no longer a limiting effect. 

As to the different possibilities for misuse, - even if they can probably be 
technically described in a uniformed way - writers have identified several areas of 
incidents, but fail to bring them back in a uniform classification [15]. This need for 
harmonization has been attempted through the channel of international bodies [16]. 

Roughly seen a categorization can be brought down along the following lines : 

• manipulation of data : input of false data, alteration, erasure, deterioration and/or 
suppression of stored data or programs with fraudulent intent. 

• data espionage : unlawful collection or acquisition and/or use of data 

• computer sabotage : leading to the destruction or disruption of soft- or hardware. 
Extensively this may include any hindering of the functioning not only of a 
computer but also of the telecommunication system. Today this includes the 
phenomenon of viruses and worms. 

• unauthorized access or interception of a computer and/or telecommunications 
system with infringement of security measures. 

• program piracy with the infringement of the exclusive right of the owner of a 
protected computer program with the intent to exploit commercially the program. 
The same can be said of a protected chip or microprocessor. 

Even if differences of labeling may occur under various initiatives [17], the major 
phenomena are clearly covered by the above list. As will shown below, not all 
countries accept the criminalization of all of these acts and the conditions of 
applicability are even more diversified. 



2 The Threat 

It would be erroneous to overscore as well as to underestimate the vulnerability of 
the information society. It is clear that from the angle of victimology, three major 
targets groups can be detected. 

1 . the individual becomes the weakest link in the new information technology era, not 
only from a sociological and economic point of view (loss of job security through 
robotics, word processing, etc...), but equally from the angle of legal protection 
(privacy). 

2. the economic targets are also rather interesting : banks, insurance companies, 
corporations of all nature become more and more vulnerable, especially where 
networks are more and more flourishing, telecommunications more and more used, 
but still hardly protected, and the cost effectiveness of certain protections not yet 
shown. Direct and indirect losses will be substantial and the effect of the law is still 
too much that of an after-the-harm reparation. 

3. the sovereign state itself, who faces a so-called erosion of sovereignty when 
noticing that many raw data can and will leave the country for economic decision- 
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making abroad (e.g. with the multinationals), the state having no insight in the 
departure of raw data or return of information and loosing impact on economic or 
financial decisions taken outside its operating or influence zone and nevertheless 
having to cope with the possessors of data and/or information. 

The key finally becomes not so much the technology itself. It is mainly 
instrumental to a far more important target which needs protection : the legal interest 
violated, whether the individual human life, the survival of an economic entity or the 
independence of the nation itself. The technology adds something, be it speed, 
massification of data or transfrontier communication. It emphasizes or amplifies, 
without necessary creating new forms of criminality. Thanks to it, information 
radically grew in importance and with it all the values attached to it, whether 
intangible or not. Much value has to go to the notion of information related 
criminality or even asset protection management, in which, besides information, 
image protection and physical securization become equally important. The massive 
presence of telematics, computers and other devices in the whole flow of information 
in our society at all levels (international, state, firm or individual) ultimately leads to 
an infiltration into the total spectrum of the legal field, the criminal, as well as the 
civil, administrative, economic, intellectual property or constitutional one. The call 
for full re-assessment of the whole of the law to make the legal system respond better 
to the problems of new information technology is real and has not been fully 
performed yet [18]. 

Looking into the legislation of mainly the industrialized nations, one notices that in 
various countries answers have been formulated [19]. Their responses differ because 
of the underlying legal system and of their appraisal of what computer-related crime 
means to them today as a threat. Even if in the more regulated field of privacy 
protection the reference frame exists with the OECD guidelines [20] the Council of 
Europe Convention for the Protection of Individuals with regard to Automatic 
Processing of Personal Data [21] and the EU DIRECTIVE OF 1995 [22] national 
laws may show diversified implementation norms or techniques [23]. One has the 
feeling that national - if not nationalistic - approaches prevail, taking the territorial - 
thus national - character of the criminal law as a starting point. 

While information criminality has an important transborder facet and data will be 
easily send and handled abroad, the need for a more global, uniform or harmonized 
approach is not always perceived or accepted. A first and maybe not optimal trend, 
therefore, is the all too national instead of cooperative response to the phenomenon. 

The efforts of the Council of Europe in the criminal law field, or of the EC in such 
areas as micro-processor, software or database protection or computer security as 
such [24], should receive priority attention and national legislatures should adjust to 
them quickly. 



3 Trendsetting in Fighting Computer-Related Criminality 

One comes to the conclusion that a valid response to the phenomenon requires a 
holistic approach, of which the three layers would be: 

1. the security issue is a threefold one: it requires technical answers, 

managerial/organizational ones and legal responses. 
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2. within the legal sphere, different branches of law have to intervene (criminal law, 
civil law, intellectual property law, labor law, etc...) 

3. within the subsets of the law the international cooperation or coordination is 
indispensable considering the increasing transborder character of the processing. 

3.1 

The issue of information security cannot be addressed by the law only. Even if 
criminal sanctions or damage allowance have, besides their reparative effect, an 
educational and preventive effect, it remains a fact that the intervention of legal 
mechanisms mostly occurs at moments when the harm is already done and the 
incident consumed. Prevention prevails over repression. To that effect, the tackling of 
this issue requires an integrated approach of technicians, economists, behaviourists, 
organizational managers and lawyers. The responsibility of computer firms is 
involved to the extent that they ought to voluntarily accept minimum security 
standards or at least make their clients aware of the vulnerable aspects of their 
computerization and require them to take sufficient starting security measures in 
relation to issues such as physical integrity of premises, access controls and 
authentication procedures, the possibility or necessity for back-ups and contingency 
planning. 

The software industry has to continue the search into security software and the 
protection of expert systems. Management and economists should develop 

more efforts towards risk analysis and cost/benefit appraisal within a given 
environment, foresee an appropriate organizational scheme adapted to the 
information flow structure; behaviourists and industrial psychologists have to look 
into the personnel hiring and training issues. 

Lawyers will have to play their part in prevention (e.g. software protection, 
contract provision, employee contracts, insurance policies) and in the elaboration of 
specific legislative initiatives in the repressive reply. 

An interesting question in relation to security is whether -in the light of the ever 
increasing number of incidents- the legislator will not interfere directly in this area 
and impose a legal duty to secure the information system [25]. 

So far regulatory provisions under domestic law specifically on compulsory 
security are barely or not present in an overall form. Requirements for security are, 
however, found within sectorial legislations related to information technology, such 
as privacy laws or computer related crime laws. The requirement is mostly phrased in 
a general manner, and contains little specifications as to its content, even though 
openings are made towards more stringent provisions, including standards to be met 
[26]. Within international circles (OECD, EC) an important activity is at the same 
time under way to achieve greater awareness and calls for action including regulatory 
initiatives [27]. 

Whether the latter will lead to imposing well defined specific requirements 
concerning products, processes and systems is as of today still unclear. In addition, a 
trend towards compulsory certification of security of information systems should 
thereby not be seen as impossible in a near future [28]. Answers could be formulated 
through law (general or sectorial) or other regulatory techniques such as codes of 
conduct. Even the latter may be made subject to approval by official instances and 
applicability to the whole sector concerned should be made a condition. In any event, 
the public and private sector should be attentive to legislative evolutions, provoke or 
participate in a cooperative dialogue with the lawmaker so as to assure that the 
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viewpoint of producers, providers of services and other users are well represented and 
that the final outcome is the result of an acceptable consensus achieving the balance 
between all interests included. 

3.2 

Today most countries do not have a cohesive information technology law. This 
obliges us to a search into different sectors so as to reach partial answers. Before 
focussing upon the criminal law, it may be interesting to mention briefly some other 
zones of legislation. 

The first area in which a generally accepted minimum solution was reached is the 
one of the protection of personal data. The centralization of data and the networking 
change radically the image a classical paper file can give of a given person. Besides 
the OECD guidelines and the Council of Europe Convention, a number of countries 
now possess specific legislation in this respect, including criminal provisions [29]. 
Within the European. Union through the directive of 1995 further harmonization is 
achieved. 

A second area is the one on software protection , via intellectual property law. The 
question whether one should start form the copyright notions, the patent law concept 
or seek for a sui generis solution has found an answer, within the copyright sphere 
[30]. Specific penal provisions can of course be built into these laws. Another area is 
the one of labor law , where most legislations foresee norms on the protection of 
industrial secrets, trade secrets or secrets related to the relationship 
employer/employee. Equally operational are legislations on unfair competition acts 
by employers during or after their contractual relationship [31]. In the law of 
contracts , secrecy or non-disclosure clauses can be build in, with provisions for fines 
in case of non-respect. Contractual responsibility rules can play in cases of unlawful 
use of information [32]. 

To be complete, one has to mention legislation in the field of telecom [33] or 
encryption [34]. In countries where deregulation is introduced (USA, Japan, U.K.), 
competition may lead to the use of security improvement as an argument in 
commerce. A breakthrough in the non-responsibility area seems the more urgent 
move to make, such as Erance did to introduce RTT-liability for gross negligence 
[35]. 

Finally, the legal spectrum also offers the insurance law as a protective barrier, 
once more to cope with casualties, i.e. after the incident. Nevertheless, a good 
management of a computer-incidents insurance portfolio can be part of a valid answer 
to criminal situation. Above all, it will need a careful cost/benefit analysis, and will 
probably have to be linked with a security level audit. 

3.3 

The extent to which transborder data flows open the risk to transborder criminality 
leads inevitably to the conclusion that valid answers depend on a harmonized, if not 
unified, approach by the industrial world. Since free flow of information is the basic 
rule, this flow must be protected and the international networks secured against 
criminal attacks. 

Comparable substantive law should be elaborated, while the international 
instruments in the field of cooperation in criminal matters be reviewed to be adapted 
to this specific criminality, a.o. to allow transborder evidence admissibility, based on 
computer-outputs. All to different legislations or non-acting countries will lead to 
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"information heavens" or "telecom crime paradises", endangering not only the 
international informational market, but also the economic or private or strategic 
interests of a given country or person, and thus potentially leading to national 
protectionist measures, certainly counterproductive in the light of the ultimate goal. 
The efforts at the level of the Council of Europe to achieve a minimum level of 
consensus on which acts should be considered criminal, deserve utmost support. 
When criminals prevail themselves of the advantage of the new information 
technology to internationalize their acts, there is no reason to remain above all in a 
nationalistic or territorial limitation in trying to formulate the answer. 



4 The Criminal Law Scene 

4.1 The Policy Issue 

When analyzing the legislations on computer related criminality, it noteworthy that 
there are important methodological differences in the approaches between national 
laws. Computer-related criminality is new to some of them, others, like the U.S., 
"benefit" from a few decades of experiences and incidents. This leads to diversified 
general policies, at least for the time being. 

One tendency is to consider the area of computer-criminality not as specific or 
totally new. Crimes against information or against property or privacy have always 
existed. Even if the new information technologies throw some particular features in 
the arena such as volume, speed or distance, it would by no means justify a new legal 
concept. The computer is to them only an instrument in the commission of a 
traditional crime, such as theft, embezzlement, violation of trade secrets, etc... No 
need for legal action in the criminal field would be necessary, emphasis would be 
upon the civil actions for damages, while the criminal judge would do with existing 
definitions, eventually going as far as some extensive interpretations. This attitude 
seems to be limited today to a few countries, which seemingly have not been affected 
by the phenomenon or, at least, in which no major court activity in computer-crime is 
noticeable [36]. 

It is our contention that no industrialized country will remain in this category, as all 
nations are facing serious challenges to the existing laws and the pressure for 
concerted action a.o. in the European context is strengthening. 

The right response is to realize that new measures are inevitable. Therein, one can 
distinguish those who prefer a low profile adaptation, i.e. the analysis of existing 
concepts, testing their applicability to computer-related situations and to take this 
dimension into account, only if needed. This can then be done through amending the 
actual provisions. Others wish to enact clearcut new incriminations either as a specific 
bill [37], or as new provision or even as, a new chapter in the penal code [38]. It has 
to be noticed, at the same time, that many countries are in the process of reviewing 
the whole of their penal code, which is certainly an excellent opportunity to include at 
an appropriate place the necessary provisions relating to information technology 
crimes [39]. 

In conclusion it seems correct to state that a large majority of concerned countries, 
together with international organizations such as the OECD or the Council of Europe, 
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are well aware of the necessity to act at legislative level, even though with variable 
intensity. 



4.2 Survey 

The analytical survey of existing laws, drafts, loopholes and problems is not an 
easy task. The Council of Europe report on computer-related crime continues to be a 
guiding document [40]. We start from the classical five-fold categorization: 
manipulations, espionage and piracy, sabotage, unauthorized use and unauthorized 
access. For once, the reversed order will be used, each time reaching a higher degree 
of criminality. To take the unlawful access and use as a starting point may be justified 
through the fact of their not so obvious association with the "crime" notion, their 
rather high frequency and potential danger, while at first glance, they belong to the 
least protected expressions of the phenomenon. 

4.2.1 Unauthorized Access of Computer- and Telecommunication System. 

Notions such as "computer hackers", "whizkids", computer-time theft are already 
familiar. As of today there is no general penalization of this activity. Some countries 
have a specific legislation [41]. Analogies may be drawn from articles incriminating 
the entrance into one's property with false or unlawfully obtained keys or wiretapping 
of conversations over telecom installations. In the field of privacy protection an 
occasional provision may be found punishing unauthorized access [42]. In some 
countries wiretapping of computer communications is punishable (Canada 178-11 
Criminal Code) (Belgium: Law of 21 march 1991 concerning the reform of certain 
economic public enterprises, art. 1 1 1 et seq.) (UK Interception of Communication Act 
1985). The Swedish privacy act (1973) includes a provision applicable if no other 
incrimination can be applied. So does the German Second Law for the prevention of 
economic crime (1986). 

Others, like the French provisions or U.S. proposals [43] go all the way towards 
the inclusion of such a provision. It must be stressed, however, that such provision 
should be - and mostly is - conditioned with several elements such as : 

• a specific intent (knowingly, without color of right) 

• the violation of security measures 

• a special request by the victim. 

Often criminal prosecution will be waived if the perpetrator informs the victim of 
the act and indicates the loopholes in the system. 

4.2.2 Unauthorized Use of Computer- and Telecommunication Systems 

Most countries do not provide a specific provision on unlawful use (furtum usus). 
Sometimes, one can rely upon unlawful use of somebody's property, which would 
more point to the hardware use. This would be possible under Danish, Finnish or 
English law. In other countries, concepts such as theft of electricity might be 
applicable (Belgium), while others require the abuse of specific objects, such as cars 
or bicycles. (Netherlands, Germany). Considering this diversity and the rising number 
of incidents of this nature, the experts both at OECD and the Council of Europe opted 
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for the introduction of specific provision in the minimum model system. Initiatives 
were already taken at individual levels. Canadian (Criminal Law Amendments Act 
1985) and American (Counterfeit Access Device and Computer Fraud and Abuse Act 
1984) initiatives have already come through, while the guidelines for national 
legislatures of the Council of Europe puts the unauthorized use in the so-called 
optional list. 

In the light of this consensual trend, uniform requirements would be a preferable 
goal. Again one may include : 

• specific intent 

• infringement of security measures 

• intent to cause harm or another form of computer-crime (loss, e.g.). 

Such a provision on "furtum usus", if made specific for information technology 
issues, requires a clear definition to distinguish between information-processors 
which should remain outside the scope (wrist watches, pocket calculators) and the real 
targets, while emphasis should go upon the functions performed and not upon the 
technological assets, since the latter will be subject to continuous evolution [44]. 

Finally, it has to be mentioned that such unauthorized use will often occur within 
the frame of an employment 

relationship or of a service contract. This indicates that much can be achieved 
through clear formulation of rights and duties in the contractual or organizational 
area, and also through security awareness initiatives in DP environment. 

4.2.3 Computer-Related Sabotage: 

If one considers this to be the destruction and/or damaging of computers, 
computercenters, data or other items linked with the computer, it is clear that this 
concept goes beyond the physical "terrorism" against corporal elements, but also 
concerns untangibles such as the data or programs themselves. Phenomena such as 
viruses and worms resort under this concept. This latter part is mostly not covered by 
notions such as property damage, vandalism, malicious mischief, since information 
can e.g. be erased without damaging or destroying the physical carrier. 

Therefore, countries, in which specific computer-crime law exists, do foresee 
either a specific comprehensive provision on this issue (American state laws e.g.), or 
an adaptation to the traditional concepts (e.g. the Canadian new sections in the 
criminal provision on "mischief : mischief in relation to data). Austria, France, 
Denmark, West Germany, etc..., seem to go for specific computer sabotage 
provisions, as does the Council of Europe. It clearly indicates that besides the 
classical protection of tangible property, in one way or another the introduction of 
penal protection against damage to data or programs is to be suggested. Again, we 
would plead for a rather high threshold, including 

• specific intent 

• detailed description of acts (destruction; damaging, rendering useless, meaningless 
or ineffective) 

• eventually, aggravating levels can be introduced if the target is an essential element 
in public administration or an economic enterprise. 
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4.2.4 Computer-Related Espionage 

The major targets to be protected here are the stored or processed data, the special 
protection to be offered to computer programs and, recently the special protection of 
computer chips. If it is clear that the illegal appropriation of one's property is 
perceived as a crime and is covered by many existing provision such as theft, 
embezzlement, larceny, the specificity here relates to the fact that some of the targets 
are not of a physical nature, but constitute "intangibles", not covered by these 
provisions. A basic discussion related to this concerns the legal status of information. 

If no proprietary rights are possible, can it then be subjects to "espionage" ? 

The protection of data stored in a computer system can eventually be looked upon 
from the traditional property law angle . The major problem of the intangible nature of 
information is sometimes explicitly solved by including express reference in the law 
(U.K. Theft Act 1968) (Australia) (USA) (Luxembourg draft). Others rely upon 
notions such as extending the idea of theft of electric impulses, since electricity is a 
tangible (hold a wire and you feel it), or assimilating it because of the economic 
values involved (Dutch and Belgian case law). 

Fundamentally, we can follow the Canadian Sub-Committee on Computer Crime, 
when opting against the property approach. The reasons are to be found in the above- 
mentioned aspects, i.e. tangible property or intellectual public good; traditional 
property/intellectual property; theft of tangible/intangible. A specific provision is 
preferable. Other linkages can be found in the trade secret and unfair competition law, 
where many countries foresee criminal provisions within their trade secrets law (W.- 
Germany, Switzerland, Austria, Greece). Others only cover partial aspects (e.g. 
fabrication secrets in Belgium, France, Luxembourg) or rely mainly on civil damages 
remedies. For the US a recommended Uniform trade secret Act has been adopted by a 
series of states. The U.K., Canada and Australia have not many penal provisions 
available, but are in the process of elaborating appropriate responses. So are the 
Scandinavian countries. This trend deserves support. The balance to be found, 
however, is here also between the legitimate right of the "owner" or "developer" to 
have his economic values in data or programs protected and the right of society to 
have ideas and discoveries accessed by anyone. 

The transborder dimension of information transfer should add even more to the 
difficulty of phrasing appropriate provisions, while the specificity of some 
informations (military, privacy, hi-tech know-how) or of some "detainers" 
(government officials, police officers, doctors, ...) equally can lead to separate or 
special rules. Should there be a "informational secrecy" as extension of the classical 
"professional secret" ? 

The way this provision should be foreseen can thus raise basic theoretical issues as 
to the status of the data which are intercepted. Anyway the interception or 
appropriation of data form part of a broader range of abuses, nl. the attack against the 
integrity of computer- or telecommunication system. This concerns more the right to 
undisturbed exchange of data than the consequences itself of acts of espionage. 

It would, therefore, be interesting not to cover the data or programs as such, but to 
search for the penal protection of the integrity of computer access to it. As conditions 
could be foreseen : the intent to harm. 

4.2.5 Computer-Related Manipulations 

The modification of data to change the processing and/or the output in order 
to obtain a change in information or at the expected consequence. In the latter case. 
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one is back into the "property" issue, (fraud, e.g.) with all its difficulties; in the 
former, forgery is the major available notion. As to fraud, the deception of a computer 
to meet the requirement that a "person" be deceived, seems problematic. Breach of 
trust is either limited to qualified persons or also requires a physical transfer of 
specific objects. Forgery is based upon visually readable documents, humanly 
understandable. Solutions de lege lata were indispensable. New laws are to be found 
in Sweden (Swedish Data Act 1974), the U.S. (Credit Card Fraud Act 1984) 
(Counterfeit Access Device and Computer Fraud and Abus Act 1981), Canada 
(Criminal Law Amendment Act 1985), Denmark (Data Kriminaliteit Law 1985), 
West Germany (Second Law for the Prevention of Economic Crime 1986). The 
Council of Europe expert report lists computer-related fraud and computer forgery 
among the "hard-core" offences to be covered by all member states [45]. 
Requirements should be a special intent (to obtain an advantage, or to harm) and a 
formulation in terms of functions and not in terms of today’s technology. 



4.3 The Transborder Issues: 

One of the more important aspects of the phenomenon is its transborder character. 
The elaboration of networks, the development of international telecommunications 
and the presence of a "multi-nationals" oriented economy certainly affect the 
traditional patterns of information transfer. 

This carries consequences to be located in the international criminal law sphere, 
more particularly those of the penal juridisdictional competences and the cooperative 
mechanisms between sovereigns. 

Answers have to be found to questions such as the localization of the crimes, the 
territoriality or extra-territoriality of them, the nature of the crime (immediate, 
continuous, collective, ...), the applicability of the cooperation structures (such as 
extradition, minor assistance, transfer of proceedings), the police-cooperation, the 
evidence issue when computer elements are included. Pluri-national incidents are 
likely to occur with the presence of things such as Swift networks, electronic mail, 
international airline reservation systems, etc... 

As to the competence- issue, the theory of ubiquity may receive a new perspective, 
whereby the situs of the act, the instrumentality situs, the situs of the potential 
consequence and the one of the actual effective consequence are difficult to locate and 
more diversified than the traditional "shot over the border" example. 

Considering the "ne bis in idem" principle, a clearer delimitation or at least 
classification of competences could become indispensable. It again points to the 
necessity of harmonized legislations. This "international connexity" throws new light 
upon concepts dating from the "before the computer" area. 

In the cooperation issue, the problem of double criminality requires once more a 
common approach. Elements of distant complicity or co-authorship require response. 
How does the notion of rogatory commission apply to evidence stored in a foreign 
database, having an untangible character or/and being accessible from front-ends in 
the requesting state? How is seizure and restitution of data conceivable between two 
states? Many are the questions raised, few are yet the answers. The work in the 
Council of Europe did not lead yet to some specific ones [46]. 
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4.4 The Procedural Issues: 

As for the transborder situation, a number of problems may occur in the domestic 
sphere. The most important issue seems here to be the admissibility of computer 
records as evidence. Most continental law countries have given much power to the 
criminal judge in the free evaluation of introduced evidence. It could be that no 
problems arise, even though the problem of authenticity of the evidence may play. In 
the common law countries, computer evidence may be regarded as "hearsay 
evidence", basically inadmissible. 

Exceptions are made or in the make, such as the U.K. Police and Criminal 
Evidence Act (Bill S-33). Requirements of accuracy, knowledge of the existence of 
the automated system and its proper use, complementary or to be supplemented by 
other proof may be retained. 



5 Conclusion 

The world of new information technology is one of the most evolutive ones. The 
somewhat mutative effect of certain of these inventions equally affects the legal 
components of societal adaptation to them. But law is not knowledgeable for quick 
responses and immediate flexibility. Especially criminal law should be preserved 
from an all too hastive reply to timely phenomena. There is a need for a minimum of 
stabilization of acts or attitudes felt as a danger to society, a sort of confirmation of 
the discovery of new anti-social behaviour and the clear creation of a sufficient 
consensus for penalization of it. The computer abuse area has now reached the 
confirmation phase : facts are clear, continuous and increasing in number and 
inventiveness. The telecommunications area is now part of the criminal scene, maybe 
not fully In the open because of the technical unawareness of the victims or their 
attitude of overdiscretion, but equally vulnerable. The time to respond is there, if we 
do not wish the phenomenon to grow unharmed, considering the loopholes in the law 
and the legal vacuum in the transborder aspects of it. Concerted action seems to be the 
only efficient one, either through conventional way or, at least, through the search for 
common thresholds. The work of the OECD and the Council of Europe should be 
regarded as the guiding trends, allowing coherent law-making activity in national 
parliaments. To build upon a broader perspective than the national frontiers and to 
benefit from international expertise in the field seem to be cornerstones for 
effectiveness. The challenge is real, the social duty to respond to it is also within the 
hands of the legal profession. 
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1 Introduction 



In this paper we give a short overview of the state of the art of secret key block 
ciphers. We focus on the main application of block ciphers, namely for encryp- 
tion. The most important known attacks on block ciphers are linear cryptanalysis 
and differential cryptanalysis. Linear cryptanalysis makes use of so-called linear 
hulls i.e., the parity of a subset of plaintext bits which after a certain number of 
rounds equals the parity of a subset of ciphertext bits with a probability suffi- 
ciently far away from one half. Differential cryptanalysis makes use of so-called 
differentials (A,B), i.e., a pair of plaintexts with difference A, which after a 
certain number of rounds result in a difference B with a high probability. The 
hulls and differentials can be used to derive (parts of) the secret key. 

Also, several extensions of the two above attacks have been introduced lately: 
the truncated differential attack 12323, the higher order differential attack 
g32n, the multiple linear attack m, and the non-linear/linear attack [TTj . 
Also, a combination of the two methods, the differential-linear attack Ea, has 
been considered. Other (general) attacks are the non-surjective attack m and 
the interpolation attack |28|. 

To improve resistance against differential and linear cryptanalysis it has been 
suggested to use power polynomials in a finite field [3lti21rl| . On the other hand, 
it has been shown that if a cipher consists solely of such functions other efficient 
attacks become possible |28| . Another well-known way of improving the security 
of a block cipher is by means of multiple encryption, i.e., where a plaintext block 
is processed several times using the same (component) block cipher with different 
keys. 

In §Elan introduction to block ciphers is given and §0 lists and discusses the 
modes of operation for encryption. In §E]we describe the theoretical and practical 
security of block ciphers. The most important methods of cryptanalysing block 
ciphers are given in § 0 § 0 discusses design principles of block ciphers, in 
particular it is shown how to build ciphers immune to the attacks described in 
previous sections. The theory of multiple encryption is described in § 0 In § 0 
we summarise our results. 



2 Block Ciphers - Introduction 

The history of cryptography is long and goes back at least 4000 years to the 
Egyptians, who used hieroglyphic codes for inscription on tombs M- Since then 
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many cryptosystems, also called ciphers, have been developed and used. Many of 
these old ciphers are much too weak to be used in applications today, because of 
the tremendous progress in computer technology. There are essentially two types 
of cryptosystems, one-key and two-key ciphers. In one-key ciphers the encryption 
of a plaintext and the decryption of the corresponding ciphertext is performed 
using the same key. Until 1976 when Difhe and Heilman introduced public-key or 
two-key cryptography m all ciphers were one- key systems. Therefore one-key 
ciphers are also called conventional cryptosystems. Conventional cryptosystems 
are widely used throughout the world today, and new systems are published 
frequently. There are two kinds of one-key ciphers, stream ciphers and block ci- 
phers. In stream ciphers a long sequence of bits is generated from a short string 
of key bits, and is then added bitwise modulo 2 to the plaintext to produce the 
ciphertext. In block ciphers the plaintext is divided into blocks of a fixed length, 
which are then encrypted into blocks of ciphertexts using the same key. Block 
ciphers can be divided into three groups: substitution ciphers, transposition ci- 
phers and product ciphers. In the following a few examples of the different types 
of block ciphers are given. 

Notation: Let Am and Ac be the alphabets for plaintexts and ciphertexts, 
respectively. Let M = mo, mi, . . . , to„_i be an n-character plaintext, s.t. for 
every i, rrii G Am and let C = cq, ci, . . . , Cn-i be a ciphertext, s.t. for every i, 
Ci G Ac- We assume that an alphabet Ax is isomorphic with IN^^. 

2.1 Substitution Ciphers 

As indicated in the name every plaintext character is substituted by some ci- 
phertext character. There are four kinds of substitution ciphers. 

— Simple substitution 

— Polyalphabetic substitution 

— Homophonic substitution 

— Polygram substitution 

We restrict ourselves to consider substitution ciphers of the first two kinds. 

Simple Substitution In a cipher with a simple substitution each plaintext 
character is transformed into a ciphertext character via the same function f. 
More formally, Vi : 0 < i < n 



f : Am Vic 

Cl = i{rrii) 

It is believed that Julius Caesar encrypted messages by shifting every letter in the 
plaintext 3 positions to the right in the alphabet. This cipher is based on shifted 
alphabets, i.e.. Am = Vic, and is in general defined as follows f(mi) = rrii k 
(mod |M»|). For the Caesar cipher the secret key k is the number 3. In general, 
the cipher is easily broken in at most \Am\ trials. Shift the ciphertexts one 
position until the plaintext arises. 
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Polyalphabetic Substitution In a polyalphabetic substitution the plaintext 
characters are transformed into ciphertext characters using a j-character key 
K = ko, . . . , kj-i, which defines j distinct functions ffeo > • ■ ■ : ffcj- j . More formally 
Vj : 0 < i < n 



ffc, : Am — > Me yi : 0 < I < j 

Ci = ffci „od j(™i) 

The Vigenere cipher was first published in 1586 m- Let us assume again that 
Am = Ac ■ Then the Vigenere cipher is defined as follows 

Ci = ffei j (^i) = rrii + ki mod j (mod \Am I) 



2.2 Transposition Systems 

Transposition systems are essentially permutations of the plaintext characters. 
Therefore Am = Ac ■ A transposition cipher is defined as follows Vz : 0 < z < n 

f : Am ^ Am 

Tj : {0, . . . , (rz — 1)} ^ {0, . . . , (rz — 1)}, a permutation 

a = f(z7Zi) = Z7Z^(i) 



Many transposition ciphers permute characters with a fixed period j. In that 
case 



f : Am ^ Am 

V ■ {0, • . • , (j - 1)} ^ {0, . . . , (j - 1)}, a permutation 

Cj f(zZZi) div j)+rj(i mod j) 

The Vigenere and in general substitution ciphers can be broken when enough 
ciphertext is available to the cryptanalyst by the index of coincidence, Kasiski’s 
method, etc. 1 1 Sf I . Transposition ciphers can be broken using the frequency 
distributions for digrams, trigrams and N-grams . The interested reader 

will find a comprehensive treatment of early cryptanalysis in m- 



2.3 Product Systems 

An obvious attempt to make stronger ciphers than the ones we have seen so far, 
is to combine substitution and transposition ciphers. These ciphers are called 
product ciphers. Many product ciphers have been developed, including Rotor 
machines m- Most of the block ciphers in use today are product ciphers. A 
product cipher is called an iterated cipher if the ciphertext is computed by 
iteratively applying a round function several times to the plaintext. In each 
round a round key is combined with the text input. 
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Definition 1. In an r-round iterated block cipher the ciphertext is com- 
puted by iteratively applying a round function g to the plaintext, s.t. 

Q = 5 (Ci_i, ATj), i = 1, r, (1) 

where Co is the plaintext, Ki a round key and Cr is the ciphertext. Decryption 
is done by reversing m, therefore, for a fixed key Ki, g must be invertible. 

In this paper we consider only iterated block ciphers and assume that the plain- 
texts and ciphertexts are bit strings of equal length. 

A special class of iterated ciphers are the Feistel ciphers, named after Horst 
Feistel 

Definition 2. A Feistel cipher with block size 2n and with r rounds is defined 
as follows. The round function is defined 

g : GF(2") x GF(2”) x GF(2"*) ^ GF(2”) x GF(2") 

g{X,Y,Z) = {Y, F(Y,Z) + X) 

where g can be any function taking two arguments of n bits and m bits respectively 
and producing n bits, ‘-h’ is a commutative group operation on the set of n-bit 
blocks. Given a plaintext P = and r round keys Ki, K 2 , ..., K^ the 

ciphertext C = (G^, G^) is computed in r rounds. Set Cq = P^ and = P^ 
and compute for i = 1,2, ..., r 

(Gf ,Gf) = (G«i,F(Gf_i,iF,) + Gf_i) 

Set Ci = (G/",G/^) and and = Cfi. The round keys {K\, ...,Kr), 

where Ki £ GF(2'"), are computed by a key schedule algorithm on input a master 
key K . 

We will assume that ‘-I-’ is the bitwise exclusive-or operation, if not explicitly 
stated otherwise. 

The Data Encryption Standard (DES) [S3| is by far the most widely used it- 
erated block cipher today. Around the world, governments, banks, and standards 
organisations have made the DES the basis of secure and authentic communica- 
tion US). The DES is a Feistel cipher, but with special properties. In general we 
define the so-called DES-like iterated ciphers. 

Definition 3. A DES-like iterated cipher is a Feistel cipher, where the F 
function is defined 



F{X,K,) = f{E{X) + K,) 

f : GF{2^) GF(2"), m>n 

E : GF(2") ^ GF(2™), an affine expansion mapping 
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3 Modes of Operations 

The most obvious and widespread use of a block cipher is for encryption. In 1980 
a list of four modes of operation for the DES was published ISH. These four modes 
can be used with any block cipher and seem to cover most applications of block 
ciphers used for encryption HH|. In the following let Ek{-) be the permutation 
induced by using the block cipher E of block length n with the key K and let 

Pi,P 2 , ,Pi,--- be the blocks of plaintexts to be encrypted. The four modes 

are 

Electronic Code Book (ECB) The native mode, where one block at a 
time is encrypted independently of the encryptions of other blocks. 

Encryption: Ci = ExiPi) 

Decryption: Pi = ExiCi) 

— Cipher Block Chaining (CBC) The chaining mode, where the encryption 
of a block depends on the encryptions of previous blocks. 

Encryption: Ci = Ex{Pi (B Ci-i) 

Decryption: P^ = Dx{Ci) 0 Cj_i 

where Co is a chosen initial value. 

— Cipher Feedback (CEB) The first stream mode, where one m-bit char- 
acter at a time is encrypted. 

Encryption: Ci = P^ ® (X*)) 

=LSB„_^(X,) II C, 

Decryption: Pi = Ci® MSBm(E/f (Xi)) 

= LSB„_™(X,) II Q 

where Xi is a chosen initial value, || denotes concatenation of blocks, MSBg 
and LSBg denote the s most and least significant bits respectively or equiva- 
lently the leftmost and rightmost bits respectively. Here m can be any num- 
ber between 1 and the block length of the cipher. If the plaintext consists of 
characters m = 7 or m = 8 is usually the well-chosen parameter. 

Output Feedback (OFB) The second stream mode, where the stream bits 
are not dependent on the previous plaintexts, i.e., only the stream bits are 
fed back, not the ciphertext as in CEB mode. 

Encryption: Ci = Pi® MSBm(Eif (X^)) 

=LSB„_^(X,) II MSB^(Ek(X,)) 

Decryption: Pi = Ci® MSB„i{Ex{Xi)) 

Xi+i = LSB„_^(X,) II MSB,„(Ek(X,)) 
where Xi is a chosen initial value. 
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In fact, both the CFB and OFB modes have two parameters, the size of the 
plaintext block and the size of the feedback value. In the above definition we 
have chosen them equal and will do so also in the following. 

The ECB is the native mode, well-suited for encryption of keys of fixed 
length. It is not suited for the encryption of larger plaintexts, since equal blocks 
are encrypted into equal blocks. To avoid this, the CBC mode is recommended. 
Not only does a current ciphertext block depend on the current plaintext but 
also on all previous ciphertext blocks. In some applications there is a need for 
encryptions of characters, instead of whole blocks, e.g., 8 bytes for the CBC 
mode of DES. For that purpose the CFB and OFB modes are suitable. It is often 
recommended to use the OFB mode only with full feedback, i.e., with m = n (64 
for the DES). It comes from the fact, that for to < n the feedback function is not 
one-to-one, and therefore has a relatively short cycle US! of length about 2"/^. 
Furthermore the initial value Xi in the OFB mode should be chosen uniformly at 
random. For example, in the case where Xi is the concatenation of njm equal 
TO-bit blocks, say (o || a || .... || a), for about keys MSBm(E/y(Ali)) = a. 

Therefore X2 = Xi and in general Xi = Xi. This is not dangerous for the CFB 
mode, where the Xi’s are also dependent on the plaintext. 



Error Propagation An important issue in the applications of the four modes 
is how an error in the transmission of ciphertexts is propagated. In the ECB 
mode an error in a ciphertext block affects only one plaintext block. A lost 
ciphertext block results in a lost plaintext block. An error in a ciphertext block 
in the CBC mode affects two plaintexts blocks. As an example, assume that 
ciphertext C3 has an error and that all other ciphertext blocks are error-free, 
then F4 = Dx(C4) 0 C3 inherits the error from C3 and P3 = Dk{C^) © C2 will 
be completely garbled. Here we assume that even a small change in the input 
to the block cipher will produce a randomly looking output. All other plaintexts 
will be decrypted correctly. A lost ciphertext block results in a lost plaintext 
block and an error in one addition plaintext block. The mode synchronises itself 
after that. In the CFB mode an error in a ciphertext block Ci will be inherited 
by the corresponding plaintext block Pi, and moreover since Xi+i contains the 
garbled Ci the subsequent plaintexts blocks will be garbled until the X value is 
free of Ci, i.e., when Ci has been shifted out. In other words in CFB mode with 
TO-bit ciphertexts, at most u/to + 1 plaintext blocks will be garbled. The case 
of lost ciphertext blocks is similar to that of the CBC mode. In the OFB mode, 
since the feedback is independent of the plain- and ciphertexts, a transmission 
error in a ciphertext block garbles only the corresponding plaintext block and is 
not propagated to other plaintext blocks. On the other hand, a lost ciphertext 
block will result in an infinite error propagation. 
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4 Security of Secret Key Block Ciphers 

When discussing the security of cryptographic systems one needs to define a 
model of the reality. We will use the model of Shannon which is depicted 
in Figure D 



Enemy 




Fig. 1. Shannon’s model of a general secrecy system. 



The sender and the receiver share a common key K, which has been trans- 
mitted over a secure channel. The sender encrypts a plaintext P using the secret 
key K, sends C over an insecure channel to the receiver, who restores C into P 
using K. The attacker has access to the insecure channel and can intercept the 
ciphertexts (cryptograms) sent from the sender to the receiver. In this section 
we assume that the legitimate sender and receiver use a secret key cipher Ek{-) 
of block size n (bits), where the key K is of size k bits. To avoid an attacker to 
speculate in how the legitimate parties have constructed their common key, we 
will assume 

Assumption 1 All keys are equally likely and a key K is always chosen uni- 
formly random. 

Also we will assume that all details about the cryptographic algorithm used by 
the sender and receiver are known to the attacker, except for the secret key. This 
assumption is known as Kerckhoffs’s Assumption m- 

Assumption 2 The enemy cryptanalyst knows all details of the enciphering 
process and deciphering process except for the value of the secret key. 

4.1 Classification of Attacks 

Using these assumptions we classify the possible attacks an attacker can do. 

— Ciphertext only attack. The attacker possesses a set of intercepted ci- 
phertexts. 
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— Known plaintext attack. The attacker obtains P\,P 2 , ■■■,Ps a set of s 
plaintexts and the corresponding ciphertexts Ci, (72, Cg. 

— Chosen plaintext attack. The attacker chooses a priori a set of s plain- 
texts P\, P 2 , ■■■, Ps and obtains in some way the corresponding ciphertexts 
Ci,C2,...,Cs. 

— Adaptively chosen plaintext attack. The attacker chooses a set of plain- 
texts Pi, P 2 , ■■■, Ps interactively as he obtains the corresponding ciphertexts 
Ci,C 2 , Cs- That is, the attacker chooses Pi, obtains Ci, then chooses P 2 
etc. 

— Chosen ciphertext attacks. For symmetric ciphers these are similar to 
those of chosen plaintext attack and adaptively chosen plaintext attack, 
where the roles of plain- and ciphertexts are interchanged. 

The chosen text attacks are obviously the most powerful attacks. In many appli- 
cations they are however also unrealistic attacks. If the plaintext space contains 
redundancy, it will be hard for an attacker to ‘trick’ a legitimate sender into 
encrypting non-meaningful plaintexts and similarly hard to get ciphertexts de- 
crypted, which do not yield meaningful plaintexts. But if a system is secure 
against an adaptively chosen plaintext/ciphertext attack then it is also secure 
against all other attacks. An ideal situation for a designer would be to prove that 
her system is secure against an adaptively chosen plaintext attack, although an 
attacker may never be able to mount more than a ciphertext only attack. 

4.2 Theoretical Secrecy 

In his milestone paper from 1949 H3| Shannon defines perfect secrecy for secret 
key systems and shows that they exist. We will now give a brief description of 
Shannon’s theory and the most important results. Let P, C and K be the random 
variables representing the plaintexts, ciphertexts and the keys respectively. Let 
Px (x) be the probability that the random variable X takes on the value x. 

Definition 4 ( |73| ) . The uncertainty (entropy) H(X.) of a random variable 
X is defined as the expectation of the negative logarithm of the corresponding 
probability distribution. 

Using the logarithm base 2, we get 

H{X) =' E[-log 2 Px{x)] = - x log 2 Px{x) 

xGsupp(Px) 



where supp{Px.) {x : Py:^{x) ^ 0}. When using this logarithm the entropy of 
X can be seen as the number of bits needed to represent (the possible values of) 
X in an optimal binary coded form. The conditional entropy of X given Y 
is defined as 

iL(X|Y) '^=1' E[-log 2 Px\Y{X\Y)] 

= - X! Py..y{x,y) xlog 2 Px\Y{x\y). 
a;,i/Gsiipp(Px,Y) 
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In other words the uncertainty about X given that Y is known. The quantity 
I{X; Y) = H(X.) — iL(X|Y) is called the information that Y gives about X. 

Definition 5 (|71i3). A secret key cipher is perfect if and only if ff(P) = 
iL(P|C), i.e., when the ciphertext C gives no information about the plaintext P . 

This definition leads to the following result. 

Corollary 1. A perfect cipher is unconditionally secure against a ciphertext 
only attack. 

As noted by Shannon the Vernam cipher, also called the one-time pad, is a perfect 
secret key cipher. In the one-time pad the plaintext characters are exclusive- 
or’ed with independent key characters to produce the ciphertexts. However, the 
practical applications of perfect secret key ciphers are limited, since, as also 
noted by Shannon, it requires as many digits of secret key as there are digits 
to be enciphered m- A less stringent form of theoretical secrecy is possible, 
defined by Shannon in terms of 

Definition 6 (irfy])- The unicity distance, Uud, of a cipher is the smallest 
number s such that there is essentially only one value of the secret key K that 
is consistent with the ciphertexts Ci,...,Cs- 

In other words, the unicity distance is the smallest s, s.t. 



The unicity distance depends on both the key size and on the redundancy in 
the plaintext space. Redundancy is an effect of the fact that certain plaintext 
characters appear more frequently than others. For a block cipher of size n, the 
redundancy p is defined as 

p= l-H(P)/n 



where P is the random variable representing the plaintexts. H{P)/n estimates 
the average number of bits of information per bit in a plaintext. 

Theorem 1 ([73|). The unicity distance of a cipher is 



'^ud — 



H{K) 

P 



where p is the redundancy of the plaintext space. 



The smallest number Nud, such that N^d is a multiple of the block size n and 
Nud > riud, is the least number of ciphertext bits an attacker needs from a 
legitimate sender in order to at least in principle be able to determine a unique 
key in a ciphertext only attack. 

Example 1 (M)- The redundancy of English language messages is about 0.8. 
So for the DES, A: = 56, n = 64 and 



70 



Therefore Nud is 128 bits, the same as two ciphertext blocks. 



Block Ciphers — A Survey 



27 



Although the unicity distance is small as in the example, it does not necessarily 
mean that the DES can be broken using only 2 known ciphertexts. First of all, 
Shannon’s measures are made using a random cipher model, but more impor- 
tant, the unicity distance gives no indication of the computational difficulty in 
breaking a cipher, merely a lower bound on the amount of ciphertext needed in 
a ciphertext only attack. However, if the plaintext space contains (close to) no 
redundancy, the unicity distance will tend to infinity, i.e., riud oo as p 0. In 
this case a ciphertext only attack will never succeed. A cipher, for which it can 
be shown that H{K\C\, ..., Cg) never approaches zero, even for large s, is called 
a strongly ideal cipher. 

One way to remove the redundancy in a plaintext space is by data compres- 
sion, but no known methods achieve perfect data compression 1421 . Since perfect 
and strongly ideal ciphers are both impractical, we also consider computationally 
secrecy, or practical secrecy. 



4.3 Practical Secrecy 

Traditionally, cryptanalysis has been very focused on finding the key K oi & 
secret key cipher. However, there are other serious attacks, which do not find the 
secret key. We classify the types of breaking a block cipher as follows, inspired by 
the classification of forgeries on digital signature systems given by Goldwasser, 
Micali and Rivest in 

— Total break. An attacker finds the secret key K . 

— Global deduction. An attacker finds an algorithm A, functionally equiva- 
lent to Ek{-) (or Dk{-)) without knowing the key K. 

— Instance (local) deduction. An attacker finds the plaintext (ciphertext) 
of an intercepted ciphertext (plaintext), which he did not obtain from the 
legitimate sender. 

— Information deduction. An attacker gains some (Shannon) information 
about key, plaintexts or ciphertexts, which he did not get directly from the 
sender and which he did not have before the attack. 



Clearly, this classification is hierarchical, i.e., if a total break is possible, then 
a global deduction is possible etc. We assume that all the above attacks are 
independent of how the keys used by the legitimate parties are chosen, i.e., we 
use Assumption n A global deduction is possible when a block cipher contains a 
“block structure” . If certain subsets of the ciphertext are independent of certain 
subsets of the plaintext, then no matter how long the key is, the block cipher 
is vulnerable to a global deduction in a known plaintext attack. Also, in iter- 
ated block ciphers the round keys are sometimes generated in a one-way fashion 
[tit>iy2ll till 7) . So in attacks, which find the round keys, it may be impossible for 
the attacker to derive the actual value of the secret key, but at the same time the 
round keys enable the attacker to encrypt and decrypt. An instance deduction 
can be as dangerous as a total break, if the number of likely plaintexts is small. 
Consider the situation where the block cipher is used for encrypting a key in a 
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key-exchange protocol. Here only one plaintext is encrypted and a total break 
is equal to an instance deduction. Information deduction is the least serious at- 
tack, however the legitimate parties are often interested in that no information 
at all about the plaintexts are obtained by any enemies, which is particularly 
dangerous if the plaintext space is highly redundant. 



Brute-Force (Trivial) Attacks. 

— Total break. All block ciphers are totally breakable in a ciphertext only 
attack, simply by trying all keys one by one and checking whether the com- 
puted plaintext is meaningful, using only about N^d ciphertexts. This attack 
requires the computation of about 2^ encryptions. 

Alternatively, one has the table look-up attack, where the attacker, encrypts 
in a pre-computation phase a fixed plaintext P under all possible keys and 
sorts and stores all the ciphertexts. Thereafter the cipher is total breakable 
in a chosen plaintext attack requiring one chosen plaintext. There might be 
some keys encrypting P into the same ciphertext. Repeating the attack a 
few times with P' ^ P will give a unique key. 

— Global/instance deduction. All block ciphers are globally/instance de- 
ducible under a known/chosen plaintext attack. Simply get and store all 
possible plaintext/ciphertext pairs. The running time of a deduction is the 
time of one table look-up. 

— Information deduction. All block ciphers are information deducible in 
a ciphertext only attack. Consider a block cipher used in the ECB mode. 
Denote two plaintexts by Pi and Pj and assume that an attacker inter- 
cepted the two corresponding ciphertext blocks, Ci and Cj. It follows that 
H{P,,PACi,Cj) < H(P,,P,), since Q ^ C, ^ P. ^ P,-, and C, = C, ^ 
P^ = Pj0. Since I{P„ Pj;Ci,Cj) = H{Pi,Pj) - H{P„ Pj\Ci,Cj), it follows 
that I{Pi, Pj]Ci,Cj) > 0, i.e., the attacker gains information about the 
plaintext blocks from two ciphertext blocks. Obviously, the more ciphertext 
blocks available to the attacker the more information is gained. A similar 
result holds for other modes. 

The information deduction just shown is trivial and results in only small infor- 
mation. The following general result shows that a non-trivial information gain 
can be obtained when about the square root of all ciphertexts are available. 

Theorem 2 ((35]). Every n-hit block cipher used in the ECB, CBC or CEB 
mode is information deducible in a ciphertext only attack with complexity about 

2^nj2 

Note that the result of Theorem |21 is independent of the key size. 

Also, Heilman m has presented a time-memory trade-off attack on any block 
cipher, which finds the secret key after 2^^/^ encryptions using 22fe/3 ^ords of 

^ Here we assume, that the attacker does not a priori have this information about the 
plaintexts. 
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memory. The 2^^/^ words of memory are computed in a pre-processing phase, 
which takes the time of 2^ encryptions. 

To estimate the complexity of a cryptanalytic attack one must consider both 
the time it takes, the amount of data that is needed and the storage requirements. 
For an n-bit block cipher the following complexities should be considered. 

— Data complexity. The amount of data needed as input to an attack. Units 
are measured in blocks of length n. We denote this complexity Cd- 

— Processing complexity. The time needed to perform an attack. Time units 
are measured as the number of encryptions an attacker has to do himself. 
We denote this complexity Cp. 

— Storage complexity. The words of memory needed to do the attack. Units 
are measured in blocks of length n. We denote this complexity Cg- 

As a rule of thumb, the complexity of an attack is taken to be the maximum 
of the three complexities, i.e., Ca = max{Cd, Cp, Cg). In general, there are some 
deviations from this rule and furthermore the three types of complexity of an 
attack are relative to the attacker. As an example, we may say that the above 
attack by Heilman on the DES has complexity ~ 2®®. Although 

the time of the pre-computation phase is 2®®, first of all, it is done only once 
after which any DES-key can be derived with complexity 2®®, secondly 2®® DES 
encryptions can be done reasonable fast in hardware on specially designed ma- 
chines m- On the other hand, the storage requirements may be unrealistic for 
most attackers, e.g., the attack on the DES will require about 1000 Gigabytes 
of memory. 



5 Cryptanalysis of Block Ciphers 

The history of cryptanalysis is long and at least as fascinating as the history of 
cryptography. As a single example, in 1917 in an article in “Scientific American” 
the Vigenere cipher was claimed to be “impossible of translation” Today, 
it is an exercise in cryptography classes to illustrate that this claim is not true. 



5.1 Differential Cryptanalysis 



The most well-known method of analysing conventional cryptosystems today 
is differential cryptanalysis, published by Eli Biham and Adi Shamir in 1990. 
The method has proved to be very efficient and cryptosystems, which have been 
conjectured strong, have been broken, for some systems (e.g., GDES) almost 
alarmingly easy |5| . Differential cryptanalysis has been applied to a wide range 
of iterated ciphers including the DES GDES [ZDCH, Lucifer IZS0, FEAL 
[ZaSSI, LOKF89 PE3|, REDOG P2], PES Khafre |S3|, SAFER gZEEEZI, 
RG5 [nS|, and IDEA p44l?Sj . For this reason the differential attack must be consid- 
ered one of the most general cryptanalytic attacks known to date. Furthermore, 
differential cryptanalysis has caused the revision and redesign of several cryp- 
tosystems and was the first attack which could (theoretically) recover DES keys 
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in time less than the expected cost of exhaustive search |t)lt)| . Differential crypt- 
analysis is universal in that it can be used against any cryptographic mapping 
which is constructed from iterating a fixed round function. We will give a brief 
description of differential cryptanalysis with respect to a general n-bit iterated 
cipher, c£, Definition QJ 

One usually defines a difference between two bit strings, X and X' of equal 
length as 

AX = X0(X')-\ (2) 

where O is the group operation on the group of bit strings used to combine the 
key with the text input in the round function and where (X)~^ is the inverse 
element of X with respect to ®. The idea behind this is, that the differences be- 
tween the texts before and after the key is combined are equal, i.e., the difference 
is independent of the key. To see this, note that 

{X (X' 0 K)-'^ =X(^K® K~^ (g) X'-i = X (g {X')-^ = AX. 

However, in a strong encryption algorithm there will be some components which 
are non-linear in the (g-operation. In a differential attack one exploits that for 
certain input differences the distribution of output differences of the non-linear 
components is non-uniform. 

Definition 7. An s-round characteristic is a series of differences defined as an 
s + 1-tuple {ooi cti, . . . , Os}, where AP = a^, ACi = ai for 1 < i < s. 

The probability of a characteristic is derived from the probability that ACi is the 
difference after i rounds given that ACi-i is the difference after i — 1 rounds. 
Define pi as the probability that inputs of difference lead to output of 
difference at, where the probability is taken over all choices of the round key 
and the inputs to the ith round. In M the notion of a Markov cipher was 
introduced. In a Markov cipher this probability is independent of the actual 
inputs of the round and is calculated over all possible choices of the round key. 
Also in m it was shown that in a Markov cipher if the round keys Ki are 
independent then the pfs are also independent and 

S 

PifACs = as I APo = ao) = n I = “-i)’ (3) 

i=l 

Experimental results on DES, LOKI, and FEAL have shown that in these 
ciphers (0 is a good approximation of the probability, when the round keys are 
dependent, e.g., derived from a key schedule algorithm. Although in general one 
defines a difference according to m, for some ciphers such as RC5, it “pays off” 
to choose another difference, which was illustrated in m- 

Assume without loss of generality that the operation (g is is the exclusive-or 
operation (0). Consider an iterated block cipher as defined in Definition dJ Let 
Cr and C' be the ciphertexts for some plaintext pair. In a chosen plaintext attack 
the cryptanalyst does not know the inputs Cr~i and C'^_i to the final round. 
However, a characteristic can be chosen so that the difference of the ciphertexts 
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after r — 1 rounds of encryptions, ACr-i, is known either completely or partially 
with probability p. Then for two ciphertexts C, C the cryptanalyst will try to 
solve the following equation for Kr 

g-\Cr,Kr)®g-\C',,Kr) = ACr-l. (4) 

Sometimes one does not recover the entire value of K^, and the remaining key bits 
are then found by an exhaustive search. The method of differential cryptanalysis 
can be summarized as follows: 

1. Find a highly probable (r — l)-round characteristic {AP^ AC \, . . . , ACr-i} 
which (partially) predicts ACr-i- 

2. Select a random plaintext P, compute P' according to AP and get the 
encryptions of the pair. Determine candidate round keys kr, which satisfy 
©• Increment a counter for each candidate round key kr- 

3. Repeat Step 2 until one round key kr is distinguished as being counted 
significantly more often than other round keys. Take kr to be the actual 
round key Kr- 

In some differential attacks using an (r — l)-round characteristic only the plain- 
text difference AP and the last ciphertext difference ACr-i need to be fixed. 
That is, the intermediate differences AC\, AC2, ■ ■ ■ , ACr-2 can have any value. 
Lai and Massey introduced the notion of differentials 03- 

Definition 8. An s-round differential is a pair of differences {q:o,q;s}, where 
AP = ao, ACs = Us- 

The probability of an s-round differential {AP, ACs) is the conditional proba- 
bility that given an input difference AP at the first round, the output difference 
at the sth round will be ACs- More formally, the probability of an s-round 
differential is given as 

Pr{ACs =/ 3 s\AP = Po) = 

S 

E En Pr(Z\C, = A|ZiC',_i=A_i), (5) 

f3i f3s-ii=l 

where ACq — AP. A differential will, in general, have a higher probability 
than a corresponding characteristic. Differentials were used by Knudsen and 
Nyberg to show how to obtain immunity against differential attacks m Also, for 
some ciphers there is a significant advantage in considering differentials instead 
of characteristics. As an example, the differential used to attack RC5 in m 
with w = 32 and 12 rounds has a probability of 2 and a corresponding 
characteristic has a probability of only 2“®®. 

Experiments on restricted versions of DES jS| showed that the number of 
chosen plaintexts needed by the differential attack is approximately 1/p, where 
p is the probability of the differential being used. 

In a differential attack the attacker does not know the key. Therefore in find- 
ing a good differential, the attacker computes the probabilities of differentials 



32 



Lars R. Knudsen 



assuming that all the round keys are uniformly random and independent. How- 
ever, the pairs of encryption an attacker gets are encrypted using the same key, 
where the round keys are fixed and (can be) dependent. Put informally “there 
is a difference between what an attacker can expect to see and what he actually 
sees”. In m this problem is dealt with as follows 

Definition 9 ((Hypothesis of stochastic equivalence)). For virtually all 
high prohahility (r — 1) -round differentials (a, (3) 

Prp{AC\ = (3 I AP = a, K = k) « PrpxiACi = (3 \ AP = a,) 
holds for a substantial fraction of the key values k. 

In a recent differential attack by Knudsen and Rijmen on IDEA j^, it was 
exploited that the hypothesis of stochastic equivalence does not hold for IDEA 
reduced to 3,5 rounds. 

Higher Order Differentials In ^3] Lai gave a definition of higher order deriva- 
tives of discrete functions. Later Knudsen used higher order differentials to crypt- 
analyse ciphers presumably secure against conventional differential attacks, i.e., 
attacks based on first order differentials m Jakobsen and Knudsen [2B! ex- 
tended these attacks and applied them to the cipher of m- We refer to 
for the definitions of higher order differentials. By the reduced cipher, we denote 
the cipher that one gets by removing the final round of the original cipher. 

The output bits of the reduced cipher are all expressible as polynomials 
GF{2)[xi,X2, ■ . ■ , Xn], where xi,X 2 , . ■ . ,Xn are (a subset of) plaintext bits. As- 
sume that these polynomials have degree not higher than d. Then according to 
pm Proposition 2] (see also PS|), we have 

where Cd denotes a d-dimensional subspace of GF{2ff, c is the same for any 
space parallel to Cd, and p is a function which computes the output from the 
reduced cipher. It follows that 

o'(w) = ^ p(x 3- w) = 0 for all w € GF{2ff (7) 

xeCd+i 

if and only if p(x) is a polynomial of degree d or lower. If d is sufficiently low, 
the block cipher can be attacked as follows. For all values of the key in the last 
round, decrypt all ciphertexts one round, obtaining the output of the reduced 
cipher, and compute the value of a(w). The keys for which a(w) ends up being 
zero are candidates for the correct value of the last-round key. By repeating the 
attack a few times only one (or a few) values of the last-round key will be left 
suggested. Jakobsen and Knudsen applied this method to the cipher example 
given in m This cipher is “provably secure” against a differential attack. In a 
higher order differential attack this cipher is broken using only 2® = 512 chosen 
plaintexts and a running time of 2^^ . 
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Truncated Differentials In some ciphers it is possible and advantageous to 
predict the values of parts of the differences after each round of the cipher. The 
notion of truncated differentials was introduced by Knudsen in m-- 

Definition 10. A differential that predicts only parts of an n-hit value is called 
a truncated differential. More formally, let (a, b) be an i-round differential. If 
o' is a subsequence of a and b' is a subsequence of b, then (o', 6 ') is called an 
i-round truncated differential. 

A truncated differential can be seen as a collection of differentials. As an example, 
consider an n-bit block cipher and the truncated differential (o', 6 ), where o' 
specifies the least n' < n significant bits of the plaintext difference and b specifies 
the ciphertext difference of length n. This differential is a collection of all 2"“” 
differentials (o, 6 ), where a is any value, which truncated to the n' least significant 
bits is o'. 

The truncated differentials were used in to attack 5 rounds of the 6 round 
SAFER K j47l4Sj in time only 2^^ with 2'^® chosen plaintexts. In m a differential 
attack using conventional differentials on SAFER K with 5 rounds was estimated 
to require more computations than a brute-force exhaustive attack. Also, in 0 
a truncated differential attack was presented on 3,5 rounds of IDEA M- 



5.2 Linear Cryptanalysis 

Linear cryptanalysis was proposed by Matsui in 1993 Bg. A preliminary version 
of the attack on FEAL was described in 1992 Linear cryptanalysis m is 
a known plaintext attack in which the attacker exploits linear approximations 
of some bits of the plaintext, ciphertext and key. In the attack on the DES 
(or on DES-like iterated ciphers) the linear approximations are obtained by 
combining approximations for each round under the assumption of independent 
round keys. The attacker hopes in this way to find an expression (0, which holds 
with probability pL ^ over all keys m, such that \pl — called the bias, is 
maximal. 

(P • a) 0 (C • /3) = (iL • 7 ) ( 8 ) 

where P, C, a,/3 , 7 are m-bit strings and where denotes the dot product. 

Given an approximation (0 a linear attack using N plaintexts and the N 
corresponding ciphertexts goes as follows. 

Linear attack PI 

1. For all plaintexts, P, and ciphertexts, C, let T be the number of times the 
left hand side of 0 is zero. 

2. If P > N /2 guess that AT • 7 = 0, otherwise guess that AT • 7 = 1. 

The attack finds one bit of information about the key, K ■ 7 , and the complexity 
of a successful attack, i.e., the number of known plaintexts needed, using the 
above algorithm can be approximated in the following way. Let T be a binomial 
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random variable taking on the value 0 with probability p. Assume that \p— 1/2 1 
is small and without loss of generality that p > 1/2. Then 

Pr(T > N/2) = ^2y/N\p - 1/2|), 

where <P is the normal distribution function. With N = |p — 1/2|“^ the success 
rate is about 97.72%. Since the required number of plaintexts is the dominating 
factor in a linear attack, the complexity, fVp, of the above linear attack is PI 

Np ~ \pL - 1 / 2|-2 

where pp is the probability of a linear approximation of the form (0 . This esti- 
mate shows that the quantity of interest in a linear attack is \pl — 1/2|“^, the 
reciprocal of the square of the bias. For DES-like iterated ciphers linear approxi- 
mations of the form @ can be found by combining linear approximations of each 
round in the cipher. As in differential cryptanalysis one can define characteristics 
to be used in linear cryptanalysis PI- 

The above linear attack is not very efficient, since it finds only one bit of 
information about the key. However, there exists an extended linear attack, which 
finds more key bits. For the DES the linear approximations used by Matsui affects 
at most one S-box per round. Only six key bits affect affect an S-box directly, 
so instead of approximating the first and last round one can simply repeat the 
attack for all values of the relevant key bits in those two rounds. One gets the 
following approximation 

(P • a) © (C • /3) © ifi) • ai) © (F(Cp, K^) ■ a.) = (if • 7 ) (9) 

where Pr, Cr are the right halves of the plain- and ciphertexts respectively. Ki 
and Kr are the key bits affecting the linear approximation in the first and rth 
rounds. For all choices of the keys K\ and the approximation m can be seen 
as an approximation of a cipher of r — 2 rounds, i.e., two rounds shorter than 
the original cipher. The attack goes as follows with N available plaintexts. 

Extended linear attack m 

1. For all, say n, values of the two keys, Ki and Kr do: 

For all plaintexts, P, and ciphertexts, C, let Ti, z = 1, ...,n, be the number 
of times the left hand side of O is zero. 

2 . Let Tmax and Tmm be the maximum and minimum values of the T^’s for 
z = 1, ...,n. If \Tjnax — N/2\ > \Tmin ~ N/2\ guess that Ki and Kr are the 
key values from the computation of Tmax ■ 

If \Tmax — N/2\ < \Tmin ~ N/2\ gucss that Ki and Kr are the key values 
from the computation of Tmin- 

In case of the DES it is conjectured and confirmed by computer experiments 
f4tlt)l)] that the efficiency of (Q decreases, when the values of Ki or Kr are 
incorrect values. In it is estimated that the complexity of an extended 

linear attack on the DES with up to 16 rounds is about 

Np^cx\pp- 1/2|-2 
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where c < 8 ing. Note that the practicality of this extended attack depends also 
on how many key bits are needed to count on in the first and last rounds. 

In |31)| Kaliski and Robshaw showed an improved linear attack using multiple 
linear approximations. In Knudsen and Robshaw showed a linear attack 
using non-linear approximations in the outer rounds of an iterated cipher. Both 
these attacks have not yet been shown to offer a significant improvement in 
attacks on the DES compared to Matsui’s linear attack. The attacks seem best 
suited for attacks on ciphers with large S-boxes, such as LOKI EE2I. 

Similar to the concept of differentials in differential cryptanalysis is the con- 
cept of linear hulls in linear cryptanalysis introduced in based on the fol- 
lowing generalisation of Parseval’s Theorem. Let X € GF(2)"^ and K € GF(2)^ 
be random variables and V = Y(X,K), Y G GF(2)", be a random variable 
which is a function of X and K. 

Theorem 3. If X and K are independent and K is uniformly distributed, then 
for all a G GF{2)^, b G GF(2)" and 7 G GF(2)^ 

2-^ \Px{X ■a + Y{X,k)-b = 0)-l/2\'^ = 

keGF(2Y 

2-^ \Px{X-a + Y{X,k)-b + k--f = 0)-l/2\^ = 

keGF(2Y 

I Px,k{X ■ a + Y{X, K)-b+K-c=0)-l/2\^ 

ceGF{2)‘ 

This theorem says that the probability of an approximation (|H|) does not 
depend on the value of 7. Moreover for the probability p of a linear approximation 
it holds that \p — l/2p is the sum of \p^ — l/2p for all values of 7. 

5.3 Differential-Linear Attack 

In Heilman and Langford showed how to combine the techniques of differ- 
ential and linear attacks. The attack is a chosen plaintext attack and considers 
pairs of plaintexts and ciphertexts, the bits of which are (partly) approximated 
by linear approximations. In particular, they illustrated the attack by devising 
an attack of the DES reduced to 8 rounds, which on input only 512 chosen plain- 
texts finds the secret key. It seems that the attack is not easily extended to more 
than 8 rounds of DES 113 - 

In P Aoki and Ohta applied the differential- linear attack to FEAL. The 
attack takes a long time, but only 12 chosen plaintexts are needed. 

5.4 Interpolation Attack 

In PSl Jakobsen and Knudsen introduced a new attack on block ciphers. The 
attack is based on the following well-known formula. Let i? be a field. Given 2n 
elements x\, . . . , Xn, yi, ■ ■ ■ ,yn G R, where the XiS are distinct. Define 
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f{x) = ^yi 

i—1 



X — Xj 
Xi — Xj 



( 10 ) 



f{x) is the only polynomial over R of degree at most n — 1 such that f{xi) = yi 
for i = 1, . . . , n. Equation cni) is known as the Lagrange interpolation formula 
(see e.g., cni page 185]). 

In the interpolation attack an attacker constructs polynomials using pairs of 
plaintexts and ciphertexts. This is particularly easy if the components in the ci- 
pher can be easily expressed as mathematical functions. The idea in the attack is, 
that if the constructed polynomials have a small degree, only few plaintexts and 
their corresponding ciphertexts are necessary to solve for the (key-dependent) 
coefficients of the polynomial, e.g., using Lagrange’s interpolation. To recover 
key bits one expresses the ciphertext before the last round as a polynomial of 
the plaintext. Subsequently, for every value of (parts of) the last-round key one 
decrypts all ciphertexts one round and uses these values in the Lagrange inter- 
polation. If a few extra plaintexts and ciphertexts fit into this polynomial, the 
correct value of the key is found with a high probability. The attack can be 
repeated until only one value of the last-round key is suggested. In an extended 
version of the attack meet-in-middle techniques are used to further reduce the de- 
grees of the used polynomials m- In particular, Jakobsen and Knudsen showed 
how to attack ciphers, which are provably secure against differential and linear 
attacks. 



5.5 Key Schedule Attacks 

In this section we consider the key schedules of block ciphers. Much research 
on the DES has been focused on the S-boxes, but a weak key schedule can be 
exploited in cryptanalytic attacks. 

We consider an n-bit block cipher, where Ek{-) denotes encryption with the 
key K and Dk{-) denotes decryption. 

Definition 11. A weak key K , is a key for which encryption equals decryption, 
i.e., Ek{X) = Dk{X) for all n-bit texts X. 

Definition 12. A pair of semi-weak keys K, K* , are keys for which encryption 
with one keys equals decryption with the other key, i.e., Ek{X) = Dk*{X) for 
all n-bit texts X or equivalently, Dk{X) = Ek*{X) for all n-bit texts X. 

It is well-known that there are at least four weak keys and six pairs of semi-weak 
keys for the DES. In HH D. Coppersmith showed that there are exactly 2^^ fixed 
points for the DES used with a weak key. 

If there are only a small number of weak keys they pose no problem for 
applications of encryption if the used keys are chosen uniformly at random. 
However, when block ciphers are used in hash modes where e.g., the key input can 
be chosen by the attacker in attempts to find collisions, they play an important 
role as demonstrated in USES!. 
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In ^21 Daemen showed that there exist a large class of 2®^ easy-identifiable 
keys for IDEA. These keys can be identified using only few plaintexts and ci- 
phertexts. Note that IDEA uses 128-bit keys. In m Vaudenay showed that for 
I in 2^® keys for Blowfish a differential attack is faster than an exhaustive key 
search. In SOI Knudsen and Meier showed that there exist a large class of differ- 
entially weak keys for RC5 inni, keys for which a specific differential attack has 
improved performance. 



Related Key Attacks In this section we consider the related key attacks. 
There are several variants of this attack depending on how powerful the attacker 
is assumed to be. 

1. Attacker gets encryptions under one key. 

2. Attacker gets encryptions under several keys. 

(a) Known relation between keys. 

(b) Chosen relation between keys. 

Knudsen introduced the method by giving a chosen plaintext attack of the first 
kind on LOKI’Ql | 33 |, reducing an exhaustive key search by almost a factor of 
four. Later Biham improved the attack ^ on LOKI’91, reducing an exhaustive 
key search by almost a factor of six, and also introduced the second kind of re- 
lated key attacks. Still later Knudsen described a related key attack on SAFER K 

and recently, Kelsey, Schneier, and Wagner m applied the related key at- 
tacks to a wide range of block ciphers. 

Note that for the attacks of 12 hi above we have to omit Assumption [D It 
may be argued that the attacks with a chosen relation between the keys are 
unrealistic. The attacker need to get encryptions under several keys, in some 
attacks even with chosen plaintexts. However there exist quite realistic settings, 
in which an attacker may succeed to obtain such encryptions, as argued in m 
Also, there exists quite efficient methods to preclude the related key attacks 




6 Design of Block Ciphers 

In this section we discuss some of the problems involved in the design of a block 
cipher. 

6.1 Design Principles 

Two generally accepted design principles for practical ciphers are the principles 
of confusion and diffusion that were suggested by Shannon. In his own words: 
“The method of confusion is to make the relation between the simple statistics of 
the ciphertext and the simple description of the key a very complex and involved 
one”. “In the method of diffusion the statistical structure of the plaintext which 
leads to its redundancy is dissipated into long range statistics” Massey 
interprets Shannon’s concepts of confusion and diffusion as follows 
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Confusion 

The ciphertext statistics should depend on the plaintext statistics in a 
manner too complicated to be exploited by the cryptanalyst. 

Diffusion 

Each digit of the plaintext and each digit of the secret key should influence 
many digits of the ciphertext. 

Shannon’s design principles are very general and informal. There have been many 
suggestions in the past of how to obtain good properties (diffusion/confusion) 
for a block cipher, but so far there is no known exact recipe of how to construct 
a secure block cipher. A necessary and obvious requirement is that the cipher is 
resistant against all known attacks, e.g., differential and linear attacks. 

We stress that a cryptographic design principle should not be over valued. 
Design principles should be seen as “guidelines” in the construction of ciphers, 
evolved from years of experience, and as necessary, but not sufficient require- 
ments. There are many examples of this in the history of cryptography. We 
already mentioned the example of EH, where a block cipher “provably secure” 
against differential and linear attacks was broken by some other means. Also, in 
M the group properties of a cryptosystem based on permutation groups were 
studied. It was claimed that the ability of a system to generate the symmetric 
group on the message space is “one of the strongest security conditions that 
can be offered”. In EH an example of a cipher was given, that generates the 
symmetric group, but still is a weak cipher vulnerable to a known plaintext 
attack. 

6.2 Block and Key Size 

It is clear from the discussion in Section lO that if either the block or key 
size is too small or both, a block cipher is vulnerable to a brute force attack. 
These attacks are independent of the internal structure and intrinsic properties 
of an algorithm. Most block ciphers, e.g., DES, IDEA, FEAL, LOKI, SAFER, 
and SHARK have a block size of 64 bits. For these ciphers the birthday attack 
of Theorem El require storage/collection of 2^^ ciphertext blocks for a success 
of about one half. This may not seem to be a realistic attack. First of all, it 
seems unlikely that a single key is used to process that many ciphertexts, second 
storage of 2^^ ciphertext blocks of each 64 bits will require about 2® Gigabytes 
of memory. Still, if an attacker can predict approximately how frequently a key 
is changed, he can repeat his attack several times with fewer ciphertext blocks 
and get a high probability of success. This should be taken into consideration, 
when designing new block ciphers. 

The key size of the DES is only 56 bits, which is too short. In a design 
of an exhaustive search machine was given, which at the cost of I million US$ 
finds the secret key of the DES in average time 3.5 hours. Most of the newest 
block cipher proposals have a larger key, e.g., IDEA EHi SAFER SK-I28 [3yi4Yj . 
SHARK |EZ), and SQUARE E3] have key sizes of 128 bits. RC5 ESI and Blowfish 
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m have variable key lengths. In 0 is was estimated that with respect to an 
exhaustive key search a key size of at least 90 bits will suffice for the next 20 
years. 

6.3 Resistance Against Differential Attacks 

We consider an r-round iterated block cipher with round function g. Denote by 
Pg the highest probability of a non-trivial one-round differential achievable by 
the cryptanalyst. 

Pg = maxmax Pr/y(Z\Ci = (3 \ AP = a) (11) 

(3 Ct^O 

where the probabilities are taken over all possible keys. In the following we will 
omit the subscript of the probabilities. The probability of a differential is given 
by(0. It is easy to obtain a lower bound of any differential in an r-round iterated 
cipher expressed in terms of Pg . 

Theorem 4 ([35j). Consider an r-round iterated cipher, which has independent 
round keys. Any s-round differential, s > 1, has a probability of at mostpg, where 
Pg is the probability of the most likely one-round differential. 

For DES-like iterated ciphers, Theorem 0 is trivial, since Pg = 1, when the 
right halves of a pair of inputs are equal. For DES-like iterated ciphers, these 
differentials are called trivial one-round differentials. It is possible to get a lower 
bound on all differentials in a DES-like iterated cipher expressed in terms of the 
most likely non-trivial one-round differential. Let now Pmax denote 

Pmax = max max Pr(Z\Ci = (3 \ AP = a) (12) 

0 OiR^O 

where an is the right half of a. We assume in the following that Pmax < 1- 

Theorem 5 ([62j). Consider an r-round iterated DES-like cipher with inde- 
pendent round keys. Any s-round differential, s > 4, has a probability of at most 
2tP 

rmax ' 

In the following section it is shown that the round function in an iterated 
cipher can be chosen in such a way that the probability of any non-trivial one- 
round differential, Pmax, is small. 

6.4 Resistance Against Linear Attacks 

As in differential cryptanalysis it is possible to get a lower bound on all linear 
approximations of an iterated cipher expressed in terms of the most likely one- 
round approximation. Let p be the probability of a linear approximation. Then 
|p— 1/2| is called the bias. Recall that the success of a linear attack is proportional 
to the reciprocal value of the square of the bias of the used linear approximation. 
Matsui showed how to treat differential and linear cryptanalysis in a similar way 
m by defining q = {2p — 1)^. Let now Qmax denote the highest such quantity 
for a one-round linear approximation. Then the following result holds. 
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Table 1. Mappings in C?_F(2”). 



Theorem 6 ( |62l51p . Consider an r-round iterated DES-like cipher with in- 
dependent round keys. Any s-round linear hull, s > 4, has a reciprocal squared 
bias of at most . 

In the following we show that there exist functions for which Pmax of every 
non-trivial one-round linear hull is small. 

Let N{f) denote the non-linearity of /, i.e., the smallest of the Hamming 
distances of any non-zero linear combination of the output coordinate functions 
to the set of all affine functions m- For a function /, where / : GF{T^) 
GF(2™) any linear approximation of / is bounded as follows, 



Qmax C: (2 



2 — i _ iV (/),2 



r = (i 



N{f) .2 

2m — 1 ' 



Differentially Uniform, Nonlinear Mappings By using the functions stud- 
ied in |61Klg§l^0| one can obtain round functions in a DES-like cipher such 
that Pmax and Qmax are small. We summarise the results of |61KII58j in Table d 
where ord{f) is the order of the coordinate functions of /. Note that squaring in 
GF(2") over GF{2) is a linear function, which means that for any of functions 
f{x) = x'^ in Table Q it holds for the functions g{x) = {f{x))'^‘ = that 
pLax = Pmax and Using these mappings and Theorems 0 and 0it 

is possible to construct block ciphers, for which one can show that every s-round 
differential or linear hull has a very low probability. 



6.5 Resistance Against Other Attacks 

As mentioned earlier one should be careful not to focus too much on the resis- 
tance against a limited set of attacks, when constructing new block ciphers. In 
some cases other attacks become possible. E.g., for some of the mappings shown 
above the output bits are only quadratic functions of the input bits, thereby 
enabling higher order differential attacks. 

Let if be a n-bit r-round iterated block cipher. Assume that the nonlinear 
order of the ciphertext bits after one round is d and d® after s rounds with a high 
probability. Then higher order differential attacks will in general not be possible 
after r rounds, if d’’ ~ n. One should take into account that the attacker may 
be able to guess key bits in the outer rounds of the cipher thereby attacking a 
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cipher with a fewer number of rounds. Thus, if the nonlinear order should reach 
the block size after, say, r — 2 rounds. 

It is yet unknown how to obtain exact security against truncated differential 
attacks. However, a truncated differential is a collection of differentials. There- 
fore, if the probabilities of all differentials can be sufficiently lower-bounded, this 
attack will have only small probability of succeeding. 

The differential-linear attack will only work if both good linear hulls and 
good differentials exist. Thus, the techniques of the previous section also apply 
in this case. 

The interpolation attack works particularly well when the outputs of one 
round of E can be described as a polynomial of the input bits with relatively 
few nonzero coefficients. Thus, if (some elements of) E cannot be described as 
such, it seems that the attack will not be possible. But the interpolation attack 
is a very new approach and needs further study. 

The key-schedule attacks can be precluded by using only so-called strong 
key-schedules m, see also 1 il 7IJ . 

7 Cascade Ciphers 

In this section, we look at methods for enhancing cryptosystems based on the 
idea of encrypting plaintext blocks more than once. In a cascade of ciphers it is 
assumed that the keys of the component ciphers are independent. The following 
result was proved by Even and Goldreich. 

Theorem 7 ( f22| ) . A cascade of ciphers is at least as hard to break as any of 
the component ciphers in attacks where an attacker cannot make use of plaintext 
statistics. 

As seen, the result establishes a connection between the security of a cascade of 
ciphers and of the underlying ciphers. The following result covering all attacks 
was proved by Maurer and Massey. 

Theorem 8 ( [SSl ) • Under any attack, a cascade of ciphers is at least as hard 
to break as the first cipher. 

The two results hold for any reasonable definition of breaking a cipher (Z2E3I, 
e.g., they hold for key-recovery attacks as well as for attacks that find a plaintext 
given a ciphertext. 

7.1 Multiple Encryption 

A special case of a cascade of ciphers is when the component ciphers are equal, 
also called multiple encryption. In the following we consider different forms of 
multiple encryption. In the following let X the underlying encryption scheme, 
and let Ek and Dk denote encryption and decryption respectively, in X under 
key K. We assume that the key space of X consists of all A:-bit strings and that 
the block length of A is m. 
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Double Encryption The simplest idea one could think of would be to encrypt 
twice using two keys K\, K 2 , i.e., let the ciphertext corresponding to P be C = 
Ek 2 {Eki (P))- It is clear (and well-known), however, that no matter how Ki, K 2 
are generated, there is a simple meet-in-the middle attack that breaks this system 
in a known plaintext attack using 2^ encryptions and 2^ blocks of memory, i.e., 
the same time complexity as key search in the original system. The memory 
requirements can be reduced significantly by using the methods of Wiener and 
van Oorschot and it is clear that this is not a satisfactory improvement over 
df. 

Triple Encryption Triple encryption with three independent keys K\,K 2 , 
and K 3 , where the ciphertext corresponding to P is (7 = Ek 3 {Ek 2 {Eki{P))), is 
also not a satisfactory solution for a similar reason as for double encryption. A 
simple meet-in-the-middle attack will break this in time about 2^^ encryptions 
and space 2^ blocks of memory. Thus we do not get full return for our effort in 
tripling the key length. We would like attacks to take time close to 2^^, if the key 
length is 3fc. In addition to this, if A = DES, then a simple triple encryption 
would preserve the complementation property, and preserve the existence of weak 
keys. Recently, it was shown that if an attacker can mount a related key attack, 
triple encryption can be broken in time about 2^= nq. The attack requires that 
the attacker can get the encryptions of a small number of known plaintexts under 
two sets of keys. The two triples of keys must differ only in the third keys with 
a difference known to the attacker. 

It is clear, however, that no matter how the three keys in triple encryption are 
generated, the meet-in-the-middle attack mentioned is still possible, and so the 
time complexity of the best attack against any triple encryption variant is not 
larger than 2^^. It therefore seems reasonable to try to generate the three keys 
from two independent A-keys Ki,K 2 , since triple encryption will not provide 
security equivalent to more than 2 keys anyway. 

Two-Key Triple Encryption One variant of this idea is well-known as two- 
key triple encryption, proposed by W. Tuchmann !ZZ|: we let the ciphertext 
corresponding to P be Eki{Dk 2 {Eki{P)))- Compatibility with a single encryp- 
tion can be obtained by setting Ki = K 2 . As one can see, this scheme uses a 
particular, very simple way of generating the three keys from K\, K 2 - 

Theorem 9 ([17j). In attacks where an attacker cannot make use of plaintext 
statistics two-key triple encryption is at least as hard to break as it is to break a 
cryptosystem that uses a single decryption function of the underlying block cipher 
for encryption. 

Even though this result establishes some connection between the security of two- 
key triple encryption with the underlying cipher, it does not (seem to) hold for 
any attacks. 

It is interesting to note that the related-key attack on a triple encryption 
scheme is not applicable to two-key triple encryption EP. However each of ATi 
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and K 2 influences only particular parts of the encryption process. Because of this, 
variants of the meet-in-the-middle attack are possible that are even faster than 
exhaustive search for Ki,K 2 - In m Merkle and Heilman describes an attack 
on two-key triple DES encryption requiring 2®® chosen plaintext-ciphertext pairs 
and a running time of 2®® encryptions using 2®® words of memory. This attack 
was refined in m into a known plaintext attack on the DES, which on input n 
plaintext-ciphertext pairs finds the secret key in time 2 ^^*^/n using n words of 
memory. The attacks can be applied to any block cipher. 

In |1 7j stronger methods for generating the keys is given. The main idea is 
to generate them pseudorandomly from 2 X keys using a generator based on the 
security of X . In this way, an enemy trying to break y either has to treat the 
3 keys as if they were really random which means he has to break X, according 
to Theorem [2 or he has to use the dependency between the keys — this mean 
breaking the generator which was also based on ff. As a concrete example the 
3-PEK scheme (for triple encryption with pseudorandomly expanded keys) was 
proposed. As before, the key length of A is fc and the block length is m. First, 
the three keys Ai, A 2 , A 3 are generated: 



X^ = EKl{EK2{IV^)) 

X 2 = Eki{Ek2{IV2)) 

X 3 = Eki{Ek2{IV3)) 

where IVi are three different initial values, e.g. IVi = C + i, where C is a con- 
stant. Subsequently, the three keys Xi are used as keys for triple encryption. 
It is shown in HZ! that if X is secure then so is y and at the same time, the 
meet-in-the-middle attacks of and the related key attack on triple en- 

cryption are not possible. Using DES as the underlying cipher, 3-PEK has 
the additional advantage to other schemes, that there are no weak keys and that 
the complementation property does not hold. 



8 Conclusion 

This paper surveyed the state of the art of cryptanalysis of block ciphers. Since 
1990 there has been a huge increase of public knowledge regarding the security of 
secret key block ciphers, most notably through the publication of the differential 
and linear attacks. Today we know how to break many systems faster than by 
an exhaustive search for the key. Still the best known attacks on many systems 
are not very practical and require either the encryptions of unrealisticly many 
chosen or known plaintexts and/or a huge memory and processing time. 
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Abstract. This paper describes the state of the art for cryptographic 
primitives that are used for protecting the authenticity of information: 
cryptographic hash functions and digital signature schemes; the hrst class 
can be divided into Manipulation Detection Codes (MDCs, also known as 
one-way and collision resistant hash functions) and Message Authentica- 
tion Codes (or MACs). The theoretical background is sketched, but most 
attention is paid to overview the large number of practical constructions 
for hash functions and to the recent developments in their cryptanalysis. 
It is also explained to what extent the security of these primitives can 
be reduced in a provable way to realistic assumptions. 



1 Introduction 

In former days, the protection of information was mainly an issue of physical 
security and selection and motivation of people. To keep information confidential, 
it was carefully locked in a vault and the discretion of the personnel prevented 
data from being disclosed. The protection of authenticity relied exclusively on 
the impossibility of forging documents (as is now still the case e.g., for visa 
and paper money) and manual signatures. The identification of people relied on 
eye-to-eye contact and information was transported by couriers. 

An important evolution was the communication of information through radio 
channels, which makes it much more vulnerable to passive eavesdropping. The 
next step was the processing of information stored on punch cards or tapes with 
digital computers. The processing capabilities of the computers increased and 
large amounts of data are now stored on magnetic or optical carriers. Transfer 
of information is realized through both local and worldwide telecommunication 
networks. Information processed in computers and under transfer in communi- 
cation networks is certainly more vulnerable to both passive and active attacks: 
it is very easy to modify the message or to change sender or recipient. This type 
of threat is especially important in the context of financial transactions and elec- 
tronic commerce. Information stored in computers can also easily be modified 
without leaving any trace. Computers are vulnerable to more specific threats: 
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computer viruses, Trojan horses, worms, and logic bombs can cause considerable 
damage. Apart from outsiders breaking into computer systems, the people oper- 
ating the computer can also be malicious. Copying or changing electronic data is 
much easier for them than modifying data stored on paper. Another application 
that will become increasingly important is the protection of the authenticity of 
pictures and moving images (e.g., video-conferencing). As one can expect that 
it will become feasible to “edit” moving pictures and make a person say and do 
things he or she never said or did, it is required that one can guarantee the au- 
thenticity of moving images through labeling techniques. This will impose high 
requirements on the throughput. Other applications where information authen- 
tication is important are alarm systems, satellite control systems, distributed 
control systems, and systems for access control. 

The intention of message authentication is to protect the communicating par- 
ties against attacks of a third party. However, a different threat emerges when 
the two communicating parties are mutually distrustful and try to perform a 
repudiation. This means that sender or receiver will try to modify a message 
and/or deny to have sent or received a certain message. This is particularly a 
problem in open environments, such as those envisaged for electronic commerce. 
A typical example of this fraud can occur in the context of electronic communi- 
cation of orders to a stockbroker. The customer can place an order to buy shares 
of company X. If some days later the transaction turns out badly, he will try to 
deny his order. If on the other hand, the transaction is successful, the stockbro- 
ker might claim that he never received the order with the intention to keep the 
profit. In the case of a dispute, a third party (e.g., a judge) has to take a decision. 
In paper documents, protection against such a fraud is offered by a handwritten 
signature and registered mail. It is clear that for electronic messages, a simple 
name at the end of the message offers no protection at all. This is analogous to 
the fact that a photocopy of a document with a manual signature is not binding, 
as one can always produce a bogus document with cut and paste operations. 
Similarly, a manual signature under a message sent through a telefax or via a 
computer network has no value. 

This paper discusses cryptographic techniques that can provide solutions to 
the problems discussed above. In the case of protection against a third party, 
the term symmetric authentication is used, and the cryptographic techniques 
employed are cryptographic hash functions. In the case of protection against 
repudiation, one uses the term asymmetric authentication and the corresponding 
cryptographic techniques are digital signatures. 

In a first part of this paper, the difference between symmetric authentication 
algorithms and digital signatures is explained in more detail, and the need for 
both techniques is demonstrated. Three approaches to solve cryptographic prob- 
lems are compared. The principles of unconditionally secure authentication are 
explained, and the complexity theoretic approach to cryptography is discussed. 
The second part deals with cryptographic hash functions; MDCs and MACs are 
treated separately. First definitions are given, and subsequently applications are 
discussed. Then an extensive overview is given of proposed schemes together 
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with a taxonomy for methods of attack. In a third part a brief overview is given 
of practical digital signature schemes. 

2 Information Authentication 

An important distinction in authentication is whether one considers symmetric 
authentication, between mutually trusting parties, or asymmetric authentica- 
tion, where one party protects a document, and the second party can only verify 
a document. The next sections discuss the two approaches. 



2.1 Symmetric Authentication 

The protection of the authenticity of information includes two aspects: 

— the protection of the originator of the information, or in ISO 7498-2 termi- 
nology |HS| data origin authentication. 

— the fact that the information has not been modified, or in ISO 7498-2 ter- 
minology the integrity of the information. 

The first aspect can be present in a hidden way if one implicitly trusts the source 
of the information (e.g., information that is read from the hard disk of a private 
laptop). Other aspects that can be important are the timeliness, the sequence 
with respect to other messages, and the intended recipient(s). 

Until the late seventies, it was generally believed that encryption of informa- 
tion suffices to protect its authenticity. The argument was that if a ciphertext 
resulted after decryption in meaningful information, it should be originated with 
someone who knows the secret key, guaranteeing authenticity of message and 
sender. Two counterexamples will show that this belief is wrong: the protection 
of integrity is dependent on the encryption algorithm and on the mode in which 
the algorithm is used. 

The Vernam cipher inni adds a random key string modulo 2 to the plaintext. 
It was shown by Shannon PIDI that this offers perfect secrecy: an eavesdropper 
learns no additional information on the plaintext from observing the ciphertext, 
no matter how much computational power she has. However, an active attacker 
can change any bit of the plaintext by simply flipping the corresponding bit of 
the ciphertext. This observation is also valid for any additive stream cipher and 
for the Output FeedBack (OFB) mode of any block cipher. It holds partially if 
the cipher is used in Cipher FeedBack (CFB) or Cipher Block Chaining (CBC) 
mode; for a definition of these modes, see the FIPS or ISO/IEC standards . 

If a plaintext longer than one block is enciphered with a block cipher in 
ECB mode, an active attacker can easily reorder the blocks. Due to the self- 
synchronization property of the Cipher Feedback Mode (CFB), any modification 
in the ciphertext will cause a corresponding modification to the plaintext and will 
subsequently garble the next part of the plaintext. When the error has shifted 
out of the feedback register, the ciphertext will be deciphered correctly again. If 
the last part of the ciphertext is modified, it is completely impossible to detect 
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this. If the garbling occurs in the middle of the plaintext, it can only be detected 
based on redundancy, as will be discussed below. 

In other modes (like the CBC mode) every ciphertext bit is a complex func- 
tion of the previous plaintext bits and an initial value. If the modification of a 
single ciphertext bit results in t bits of the plaintext being garbled, the proba- 
bility that the new plaintext will be accepted as meaningful equals 2“*'°, where 
D is the redundancy in the information. In the case of natural language, coded 
with 5 bits per character, the redundancy per bit D « 0.74, and this probability 
is equal to for t = 64. However, if Z? = 0 all messages are meaningful, and 

encryption offers no authentication, independently of the encryption algorithm 
or of the mode. Note that even if redundancy is present, a human checker or a 
designated computer program is required to check its presence. If an intelligent 
attacker comes into play, the natural redundancy offers little protection, with 
the exception of a ciphertext only setting (in that case an attacker does not know 
beforehand what the corresponding plaintext will be; but there exist applications 
for which such a ‘weak’ attack may cause serious problems). If however a number 
of plaintext-ciphertext pairs are known, the encryption becomes vulnerable to 
splicing attacks. In a chosen plaintext or chosen ciphertext setting, none of the 
standard encryption modes offers any protection against such attacks. 

In order to protect the integrity, a special form of redundancy has to be 
added, and if the information is to be linked with an originator, a secret key has 
to be involved in the process (this assumes a coupling between the person and 
his key), or a separate integrity channel has to be provided. Hence two basic 
methods can be identified. 

— The first approach is analogous to that of a symmetric cipher, where the 
secrecy of large data quantities is based on the secrecy and authenticity of 
a short key. In this case the authentication of the information also relies on 
the secrecy and authenticity of a key. To achieve this goal, the information is 
compressed to a quantity of fixed length, which is called a hash result. Sub- 
sequently the hash result is appended to the information. The function that 
performs this compression operation is called a hash function. The basic idea 
of the protection of the integrity is to add redundancy to the information. 
The presence of this redundancy allows the receiver to make the distinction 
between authentic information and bogus information. 

In order to guarantee the origin of the data, a secret key that can be associ- 
ated to the origin intervenes in the process. The secret key can be involved 
in the compression process or can be used to protect the hash result and/or 
the information. In the first case the hash result is called a Message Authen- 
tication Code or MAC, while in the latter case the hash result is called a 
Manipulation Detection Code or MDC. 

— The second approach consists of basing the authenticity (both integrity and 
origin authentication) of the information on the authenticity of a Manipu- 
lation Detection Code or MDC. A typical example for this approach is a 
computer user who will calculate an MDC for all its important files. He can 
store this collection of MDCs on a floppy, that is locked in his safe, or he 
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can write them down on a piece of paper. If he has to transfer the files to a 
remote friend, he can simply send the files and communicate the MDCs via 
telephone. The authenticity of the telephone channel is offered here by voice 
identification. 

Note that the addition of redundancy is not sufficient. Additional measures 
are required to protect against high level attacks, such as the replay of an au- 
thenticated message (cf. Sect. I8.3|l . 

Both approaches do not work if sender and receiver do not trust each other. 
In the first approach, they share the same secret key. If one of the parties claims 
that the information was changed by the other party, a judge cannot make a 
distinction between them, even if they disclose their common secret key. The 
second approach can only provide non-repudiation if both parties trust the au- 
thenticity of the MDC: in practice however this is difficult to realize, as both 
parties have a similar access to that channel. 



2.2 Asymmetric Authentication 

If one wants to be protected against insider attacks, one needs an electronic 
equivalent of a manual signature. In this case a third party will be able to dis- 
tinguish between both parties, based on the fact that the capabilities of both 
parties are different. The concept of a digital signature was introduced by Difhe 
and Heilman in 1976 |SD|. The requirements are that the signature depends on 
the information to be signed (since it is not physically connected to the docu- 
ment) and that the signer is the only person who can produce a signature (this 
means no one else can forge a signature, which implies that the signer cannot 
deny that he has produced it). A digital signature scheme consists of the follow- 
ing elements: 

— an initialization phase (e.g., key generation and general setup); 

— a signing process, where the signature is produced; 

— a verification process, where the receiver (or a judge) verifies whether the 
signature is correct. 

Digital signatures in this sense can be produced based on tamper resistant de- 
vices, conventional one-way functions, or public-key techniques. Sect. 0provides 
a brief overview of practical signature schemes. 

Several generalizations have been defined, with more players in the game and 
with different notions of security. Examples of such extensions are: arbitrated 
signatures, where the signing and verification process involves interaction with 
a third party, group signatures, where signers and/or verifies are members of a 
group, blind signatures, where the signer signs a ‘blinded’ or ‘masked’ message, 
and undeniable signatures, where the signature can only be verified with the 
cooperation of the signer. For a more extensive treatment of digital signature 
schemes the reader is referred to the Handbook of Applied Cryptography [I 1 5j 
and the work by Pfitzmann pm] . 
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3 Three Approaches in Cryptography 

In modern cryptography, three approaches can be identified; they differ in the 
assumptions about the capabilities of an opponent, in the definition of a crypt- 
analytic success, and in the notion of security. Our taxonomy deviates from the 
approach by Simmons and is based on the taxonomy for stream ciphers 

of Rueppel una. A first method is based on information theory, and it offers 
unconditional security, i.e., security independent of the computing power of an 
adversary. The complexity theoretic approach starts from an abstract model 
for computation, and assumes that the opponent has limited computing power. 
The system based approach tries to produce practical solutions, and the secu- 
rity estimates are based on the best algorithm known to break the system and 
on realistic estimates of the necessary computing power or dedicated hardware 
to carry out the algorithm. Simmons lumps the second and third approach to- 
gether as computationally secure and Rueppel defines a fourth approach 

in which the opponent has to solve a problem with a large size (namely examin- 
ing a huge publicly accessible random string) pi 57) : it can be considered as both 
computationally secure and information theoretically secure. 

3.1 Information Theoretic Approach 

This approach results in unconditionally secure solutions, which implies that the 
security of the system is independent of the computing power of the opponent. 
E.g., for privacy protection, it has been shown by Shannon \m that uncondi- 
tional privacy protection requires that the entropy of the key is lower bounded 
by the entropy of the plaintext. Note that both unconditional privacy and un- 
conditional authenticity are only probabilistic: even if the system is optimal 
with respect to some definition, the opponent has always a non-zero probabil- 
ity to cheat. However, this probability can be made exponentially small. Until 
recently, it was widely believed that unconditionally secure schemes for authenti- 
cation were as impractical as the Vernam scheme; however, during the last years 
schemes have been developed which are extremely efficient both in terms of key 
usage and in terms of computation. 

The idea of unconditionally secure authentication dates back to the early sev- 
enties, when Simmons was developing for Sandia National Laboratories a system 
for the verification of treaty compliance, such as the comprehensive nuclear test- 
ban treaty between the USA and the USSR uns!. The first technical solution 
to the problem appeared in 1974 in a paper by Gilbert et al. m Subsequently 
the theory has been developed further by Simmons, analogous to the theory of 
secrecy systems that was invented by Shannon m. An overview of this the- 
ory can be found in the work of Simmons and Stinson unsnEzi. Recent 
developments can be found in the work of Kabatianskii et al. ra- 

From the brief but clear summary by Massey in uni we can cite the fol- 
lowing statement “The theory of authenticity is in many ways more subtle than 
the corresponding theory of secrecy. In particular, it is not at all obvious how 
“perfect authenticity” should be defined.” This is caused by the fact that there 
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are different bounds that can be met with equality. In this section we will give 
the basic definitions, discuss briefly a taxonomy, and give (without proof) the 
most important theoretical bounds. We conclude with a brief overview of the 
recent efficient construction. 



Definitions and Notation. In the literature on this subject, the information 
to be communicated is called the source state, while the information that will be 
sent to the receiver is called the message. A mapping between the space of source 
states and the message space is called an encoding rule. The set of source states, 
messages, and encoding rules is called an authentication code. In the following 
we will keep the more usual terminology of plaintext, ciphertext, and key. The 
set of plaintext, ciphertexts, and keys will be denoted with {P}, {C}, and {K} 
respectively. The size of plaintext, ciphertext, and key space will be denoted with 
p, c, and k. 

As usually in cryptography, the main players are the sender Alice, who wants 
to send some information to the receiver Bob; the opponent of Alice and Bob is 
the active eavesdropper Eve, who can perform three types of attacks: 

— Eve can send a fraudulent cryptogram to Bob as if it came from Alice (im- 
personation attack); 

— Eve can wait until she observes a cryptogram and replace it by a different 
cryptogram (substitution attack); 

— Eve can choose freely between both strategies (deception attack). 

The probability of success (when the strategy of Eve is optimal) will be denoted 
with Pi, and Pd respectively. A first result that follows from Kerckhoffs’ 
assumptiorjj (namely that the strategy to choose the key is known by Eve) is 
that 

Pd = max(Pi, Ps) . 

A basic distinction that can be made in this theory is between authentication 
codes with and without secrecy. In the latter case the plaintext can be derived 
easily from the ciphertext. The corresponding codes are called Cartesian or sys- 
tematic. In this case one can write the ciphertext as the concatenation of the 
plaintext P with an authenticator. Message Authentication Code, or MAC. The 
number of authenticators is denoted with p. In the following the assumption 
will be made that the authenticator is a deterministic function of the plaintext 
and the key (in technical terms: only authentication codes without splitting are 
considered) . 



Bounds on Authentication Codes. The simplest bound that can be given 
is for an impersonation attack: if Eve selects C completely at random from the 



^ The Dutchman A. Kerckhoffs (1853-1903) was the first to state the principle that 
the security of a cipher must reside entirely in the secrecy of its key. 
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c cryptograms that occur with nonzero probability in the authentication code, 
her probability of success can be lower bounded by the following expression: 



Pr > 



c 

which is called the combinatorial bound for impersonation. For Cartesian codes 
this bound becomes Pi > 1/p. 

If no splitting occurs, a similar bound can be given for substitution: 



Ps > 



p-1 



C- 1 ’ 



which is called the combinatorial bound for substitution. 

The next bound is based on the concept of mutual information, and is also 
called the ‘authentication channel capacity’ theorem: 



For the shortest proof known until now and a discussion of the recent improve- 
ments on this bound by Johannesson and Sgarro the reader is referred to mu. 
A formulation in words is that the difference between the amount of information 
transmitted through the channel and that needed by the receiver to resolve his 
uncertainty about the plaintext can be used to authenticate the plaintext, and 
conversely no better result can be achieved. One can now show that 



Pd> 



1 

y/k 



( 1 ) 



This means in practice that the security level {—log 2 Pd) is at most half the 
key size in bits. For Z-fold secure schemes where an opponent can first observe I 
ciphertexts, this has been extended by Fak to 



The next step is to define perfect authenticity to mean that equality holds in 
the equation for the authentication channel capacity. Note that even if a system 
is perfect, Pd will only be small if the cryptogram C reveals much information 
about the key K . Two simple examples of perfect authentication codes are given 
in Table ^ 

Massey shows that perfect authenticity schemes are less efficient in terms 
of key bits than schemes that provide perfect secrecy mm. To be more in line 
with the rest of this paper, from now on p and c will be powers of two: an r-bit 
message will be authenticated with a m-bit MAC, or p = 2’’ and c = 2’'+"*. 
m if an r-bit plaintext is mapped to an (r -|- 77i)-bit ciphertext, the number 
of key bits per plaintext bit for perfect authenticity with Pi and Pg equal to 
the combinatorial bound is at least m/r, which is much larger than 1 if r is 
small. Note that Pi = 1/2"*, so m cannot be small. However, unlike for secrecy, 
authenticity does not have any need for perfect schemes. As will be explained 
below, if Pg is allowed to be slightly smaller than Pi, the key size can be close 
to minimal (that is, as indicated by and this for both short and very long 
messages. 
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Table 1. A perfect Cartesian authentication code and a perfect authentication 
code that also provides perfect secrecy m 
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Practical Cartesian Authentication Codes. This section presents more 
practical authentication schemes. The problem with the perfect constructions 
is that a key of at least 2m bits is required. Moreover, a theorem by Stinson 
states that if Pi — Pg = 1/2"*, the number of plaintexts is at most a linear 
function of the number of keys. The idea is to reduce the key size at the cost 
of a small increase of Pg. Such constructions were already published by Carter 
and Wegman in the late seventies under the name of strongly universal hash 
functions PSHZH. Kabatianskii et al. m showed that if Pg exceeds Pi by an 
arbitrarily small amount, the number of plaintexts grows exponentially with the 
number of keys. This research developed from exploring connections to the rich 
theory of error-correcting codes. The price to be paid is that m has to be slightly 
larger to achieve the same value of Pd as for the perfect schemes. 

Krawczyk has considered universal hash functions that are linear with respect 
to bitwise exor |i()4im,N| . This property makes it easier to reuse the authentica- 
tion code (with the same key): one encrypts the m-bit hash result for each new 
message using a one-time pad. This approach leads to very simple constructions 
and proofs for constructions based on polynomials and Linear Feedback Shift 
Registers (LFSRs). For the case Pg = 2 ■ Pi, the most efficient construction to 
date is that of Kabatianskii et al. All these constructions use a composition: 
the bulk of the hashing is done with a function with weaker properties, and the 
stronger properties (which require a larger keys size) are only used for the final 
stage. Several of these schemes are based on the evaluation of polynomials over 
a finite field; Shoup una and Afanassiev et al. Q have studied efficient software 
implementations of this primitive. These schemes offer the best performance for 
small key sizes and hash results. 

A second line of research has been to improve the speed at the cost of an 
increased key size and size of the hash result. Rogaway has introduced bucket 
hashing in HSH; a slower variant with shorter keys was introduced by Johansson 
in [ 03 . Halevi and Krawczyk have designed an extremely fast scheme which 
makes optimal used of the multiply and accumulate instruction of the Pentium 
MMX processor (1 Gbit/s on a 200 MHz Pentium Pro) |SH. Such high speeds 
can be obtained because authentication codes have combinatorial rather than 
cryptographic properties. 

As an example, a construction based on Reed-Solomon codes is described; 
this scheme was first published by Mehlhorn and Vishkin ina . The key consists 
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of 2 elements of GF(2"*) denoted with /j, and v. The argument x is split into 
elements of GF(2™) denoted with Xi, X 2 , . . . , Xt, hence r = t-m. The function 
is then defined as follows: 



t 

g{x) = fi + Y^ Xi-v\ 

i=l 

where the addition and the multiplication are in GF{2'^). It can be shown that 
this yields an authentication code with Pi = 2“"* and Pg = {rjrnjjT^ = t/2"*. 
It is clear that this scheme can be generalized to any finite field. If r = m this 
construction reduces to the construction for a perfect authentication code by 
Gilbert et al. m 

The schemes discussed in this section have the property that the secret key 
can be used for one message only. However, if the construction is additive, it is 
sufficient to refresh the last part of the key, which ‘encrypts’ the output (the 
value of /r in the last example). In practice, this value can be computed from a 
short key by using a pseudo-random bit generator (with only computational or 
heuristic security), as suggested by Brassard |^; as a consequence, the resulting 
scheme is no longer unconditionally secure, but it is clear on what the security is 
based. It is then essential that this pseudo-random bit generator is very strong. 
For long messages, the overhead of computing the key is compensated by the 
much higher evaluation speed of the authentication code. For short messages, 
conventional MAC algorithms as discussed in Sect. I4.,sl a,re still more efficient. 



Unconditionally Secnre Digital Signatures. Under certain assumptions, 
it is possible to construct digital signatures that are unconditionally secure for 
signer or receiver (this implies that even infinite computing power will not en- 
able the other party to cheat with a significant probability). If the number of 
participants is limited, the construction of Chaum and Roijakkers provides 
unconditionally secure signature schemes, that is, digital signatures that are un- 
conditionally secure for both signer and receiver. 



3.2 Complexity Theoretic Approach 

The approach taken here is to define a model of computation, like a Turing 
machine or a Boolean circuit |3]. All computations in this model are param- 
eterized by a security parameter, and only algorithms or circuits that require 
asymptotically polynomial time and space in terms of the size of the input are 
considered feasible. The next step is then to design cryptographic systems that 
are provably secure with respect to this model. This research program has been 
initiated in 1982 by Yao and tries to base cryptographic primitives on 
general assumptions. Examples of such primitives are: secure message sending, 
cryptographically secure pseudo-random generation, digital signatures, and bit 
commitment. Examples of general assumptions to which these primitives can be 
reduced are the existence of one-way functions, injections, or permutations, and 
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the existence of trapdoor one-way permutations. A third aspect is the efficiency 
of the reduction, i.e., the number of executions of the basic function to achieve a 
cryptographic primitive, and the number of interactions between the players in 
the protocol. For practical applications, the tightness of the redundancy is also 
important, i.e., the relation between the security of the building blocks and that 
of the resulting scheme. 

An important research goal is to reduce cryptographic primitives to weaker 
assumptions, with as final goal to prove that the reduction is optimal. One can 
also try to improve the efficiency of a reduction, possibly at the cost of a stronger 
assumption. If someone wants to build a concrete implementation, he will have 
to choose a particular one-way function, permutation, etc. The properties of 
a particular problem that is believed to be hard can be used to increase the 
efficiency of the solutions. Examples of problems that have been intensively used 
are the factoring of a product of two large primes, the discrete logarithm problem 
modulo a prime and modulo a composite that is the product of two large primes, 
and the quadratic residuosity problem (see for example Sect.|S|). 

The complexity theoretic approach has several advantages: 

1. It results in provable secure systems, based on a number of assumptions. 

2. The constructions of such proofs requires formal definitions of the crypto- 
graphic primitives and of the security of a cryptographic primitive. 

3. The assumptions on which the security of the systems is based are also 
defined formally. 

The disadvantage is that the complexity theoretic approach has only a lim- 
ited impact on practical implementations, due to limitations that are inherently 
present in the models. 

1 . In complexity theory, a number of operations that is polynomial in the size of 
the input is considered to be feasible, while a superpolynomial or exponential 
number of operations in the size of the input is infeasible. In an asymptotic 
setting, abstraction is made from both constant factors and the degrees of 
the polynomials. This implies that this approach does not always provide 
information on the security of concrete instances (a practical problem has 
a finite size). Moreover, the scheme might be impractical because the num- 
ber of operations to be carried out is polynomial in the size of the input 
but impractically large. Even if the cost in efficiency of a provable scheme 
compared to an ad hoc scheme is moderate, one is not always inclined to 
select provable secure solutions. Recently more attention has been paid to 
this aspect, and several results are known which provide tight and efficient 
reductions to the security of primitives of fixed size. Example are the security 
analysis of HMAC and CBC-MAC by Bellare et al. |l(il4) . 

2. The complexity theoretic approach yields only results on the worst case or 
average case problems in a general class of problems. However, cryptogra- 
phers studying the security of a scheme are more interested in the subset of 
problems that is easy. 

3. Complexity usually deals with single isolated instances of a problem. A crypt- 
analyst often has a large collection of statistically related problems to solve. 
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A few theoretical results on information authentication will be summarized 
briefly. Their importance will only be appreciated after reading Sect. 0 Naor 
and Yung have introduced the concept of a Universal One-Way Hash Function 
(UOWHF) |128^ (not to be confused with a universal hash function, cf. Sect. Q). 
The idea behind a UOWHF is that first the input is selected and subsequently 
(and independently) the hash function. In this case it does not help an opponent 
to And collisions for the hash function (cf. Sect. 14.211 . Naor and Yung show how 
to use a UOWHF to build a signature scheme. An important result is that it is 
sufficient to have a UOWHF that compresses a single bit to construct a UOWHF 
that compresses an arbitrary number of bits. Several authors have subsequently 
improved their construction. A key result by Rompel is a (very inefficient) 
construction for a UOWHF based on any one-way function, which is the weakest 
possible assumption. Bellare and Rogaway propose efficient constructions for 
UOWHFs, which they call ‘target collision resistant hash functions’ or TCRs HH. 
They also show that if such a primitive is built from a compression function (cf. 
Sect. I5. ljl . a different approach is required than for the hash functions discussed 
in Sect. 0 

A second result by Damgard is a construction for a CRHF (Collision 

Resistant Hash Function) based on a collision resistant compression function 
with fixed size input (see Theorem in Sect. Oil . 

A recent result by Simon nm provides a motivation to treat collision resis- 
tant hash functions as independent cryptographic primitives. He shows hat no 
provable construction of a CRHF can exists based on a “black box” one-way 
permutation, i.e., a one-way permutation treated as an oracle. 



3.3 System Based or Practical Approach 

In this approach schemes with fixed dimensions are designed and studied, paying 
special attention to the efficiency of software and hardware implementations. 
The goal of this approach is to ensure that breaking a cryptosystem is a difficult 
problem for the cryptanalyst. 

By trial and error procedures, several cryptanalytic principles have emerged, 
and the designer intends to avoid attacks based on these principles. Typical 
examples are statistical attacks and meet-in-the-middle attacks. An overview of 
these principles for MDCs and MACs is presented in Sect. 0 and |H1 

The second aspect is to design building blocks with provable properties. 
These building blocks are not only useful for cryptographic hash functions, but 
also for the design of block ciphers and stream ciphers. Typical examples are 
statistical criteria, diffusion and confusion, correlation, and non-linearity criteria. 
For more details, see Preneel et al. m- 

Third, the assembly of basic building blocks to design a cryptographic hash 
functions can be based on theorems. Results of this type are often formulated 
and proven in a complexity theoretic setting, but can easily be adapted to a more 
practical definition of “hardness” that is useful in a system based approach. A 
typical example is the theorem discovered independently in and HEl, stating 
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that a collision-resistant hash function can always be constructed if a collision- 
resistant function exists, where the first reference uses a complexity theoretic 
approach and the second a more practical definition. 



4 Cryptographic Hash Functions 

Sect.O has explained how the authenticity of information can be verified through 
the protection of the secrecy and/or the authenticity of a short imprint or hash 
result. This section presents definitions and applications of hash functions that 
use a secret key (Message Authentication Codes or MACs) and for hash func- 
tions that do not make use of a secret key (Manipulation Detection Codes or 
MDCs). 

A brief discussion of the existing terminology can clarify the confusion in 
the literature. The term hash functions originates historically from computer 
science, where it denotes a function that compresses a string of arbitrary length 
to a string of fixed length. Hash functions are used to allocate as uniformly 
as possible storage for the records of a file. The name “hash functions” has 
also been widely adopted for cryptographic hash functions or cryptographically 
strong compression functions, but the result of the hash function has been given 
a wide variety of names in cryptographic literature: hash code, hash total, hash 
result, imprint, (cryptographic) checksum, compression, compressed encoding, 
seal, authenticator, authentication tag, fingerprint, test key, condensation. Mes- 
sage Integrity Code (MIC), message digest, etc. The terms MAC and MDC 
originated from US standards and are certainly not perfect (a MAC or an MDC 
are actually no codes, and both can serve for message authentication), but the 
adoption of these terms offers a pragmatic solution. One example of the confu- 
sion is that “checksum” is associated with the well known Cyclic Redundancy 
Checks (CRC) that are of no use for cryptographic applications. In this paper 
the names MAC and MDC will also be used for the hash result obtained with a 
MAC and an MDC respectively; the algorithm that computes the MAC result is 
often called the MAC algorithm. Sometimes a MAC algorithm is called a keyed 
hash function, but then one has to use for an MDC the artificial term unkeyed 
or keyless hash function. Moreover, some people understand by this definition 
an MDC that has an input containing a secret key. The class of MDCs will 
be further divided into one-way hash functions (OWHF) and collision resistant 
hash functions (CRHF). The term collision resistant hash function (CRHF) is 
preferable over strong one-way hash function, as it explains more clearly the ac- 
tual property that is satisfied. The term collision free hash function proposed by 
Damgard is also more explicit, but can be slightly misleading: in fact collisions 
do exist, but it should be hard to find them. An alternative that was proposed 
by Zheng et al. in msi is collision intractible hash functions. The term weak 
one-way hash function was proposed by Merkle in HE!, in order to stress the 
difference with a strong or collision resistant hash function. Finally note that in 
a complexity theoretic context the concept of universal one-way hash function 
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(UOWHF) was defined by Naor and Yung in )l2?Sl (cf. Sect. i;i.2l) . The relation 
between several cryptographic hash functions has been summarized in Fig. ^ 

cryptographic hash function 




MAC MDC 




OWHF CRHF 



Fig. 1. A taxonomy for cryptographic hash functions 



In the following the hash function will be denoted with h, and its argument, 
i.e., the information to be protected with X. The image of X under the hash 
function h will be denoted with h{X)\ the notation }ik{X) will be used for a 
MAC, with K the secret key. It will be assumed that the description of the hash 
function h is publicly known; the computation of an MDC does not require any 
secret information, while the only secret information for a MAC algorithm lies 
in the key. This is an extension of Kerckhoffs’ principle. A second assumption is 
that given the inputs, the computation of the hash result must be “easy”. 

4.1 One-Way Hash Function (OWHF) 

The concept of one-way hash functions was introduced by Difhe and Heilman in 
pg. The first informal definition was apparently given by Merkle and 

Rabin 

Definition 1 A one-way hash function is a function h satisfying the follow- 
ing conditions: 

1. The argument X can be of arbitrary length and the result h{X) has a fixed 
length of n bits (with n > 64 ... 80/ 

2. The hash function must be one-way in the sense that given aY in the image 
of h, it is “hard” to find a message X such that h(X) = Y (preimage resis- 
tant) and given X and h{X) it is “hard” to find a message X' / X such 
that h{X') = h{X) (second preimage resistant). 

Note that this last condition (finding a second preimage is “hard”) differs from 
the intuitive concept of one-wayness, namely that it is “hard” to find a preimage 
X given only h and the value of h{X). It is clear that for permutations or 
injective functions only preimage resistance is relevant. The relation between 
preimage resistance and second preimage resistance is discussed in |ll.^l.‘14j . 
Formal definitions of a OWHF can be obtained through insertion of a formal 
definition of “hard” and “easy” in combination with the introduction of a security 
parameter. 
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4.2 Collision Resistant Hash Function (CRHF) 

The importance of collision resistance for hash functions used in digital signature 
schemes was first pointed out by Yuval in mg. The first formal definition of 
a CRHF was apparently given by Damgard piTET] . An informal definition was 
given by Merkle in mBi. 

Definition 2 A collision resistant hash function is a function h satisfying 
the following conditions: 

1. The argument X can be of arbitrary length and the result h{X) has a fixed 
length of n bits (with n > 128 . . . 160 ). 

2. The hash function must be one-way, i.e., preimage resistance and second 
preimage resistant. 

3. The hash function must be collision resistant: this means that it is “hard” to 
find two distinct messages that hash to the same result. 

Finding a second preimage cannot be easier than finding a collision: therefore 
the second preimage condition in this definition is redundant. However, preimage 
resistance is not necessarily implied by collision resistance, while it is required 
for certain applications. Damgard provides some definitions and conditions un- 
der which collision resistance implies preimage resistance m see also Gibson’s 
comment in Hg. 

For a practical definition, several options are available. In the case of “ideal se- 
curity,” defined by Lai and Massey [1107) . producing a (second) preimage requires 
about 2" operations and producing a collision requires about 2"/^ operations 
(see Sect. EJ, but in practice it may be sufficient that both are computationally 
infeasible. 



4.3 Message Authentication Code (MAC) 

Message Authentication Codes have been used for a long time in the banking 
community and are thus older than the open research in cryptology that started 
in the mid seventies. However, MAC algorithms with good cryptographic prop- 
erties were only introduced after the start of open research in the field. The first 
reference to a MAC is a 1972 patent application by Simmons et al. (reference 
10. in ITHI L 

Definition 3 A MAC is a function h satisfying the following conditions: 

1. The argument X can be of arbitrary length and the result hx^X) has a fixed 
length of n bits (with n > 32 . . . 64, cf. Sect. |g). 

2. Given h and X, it is “hard” to forge a MAC on a new message, that is, 
to determine hxiX) with a probability of success “significantly higher” than 
1/2". Even when many pairs {A^, fi,/y(Aj)} are known, where the Xi have 
been selected (sequentially) by the opponent, it is “hard” to compute hxiX') 
for any X' ^ Xi. 
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The last attack is called an adaptive chosen text attack; see Sect. 0for more 
details. One distinguishes between forgery attacks and key recovery attacks: a 
forgery allows to determine the MAC on a new message; a key recovery attack 
is much more serious as it allows to forge any arbitrary message. Note that 
resistance to forgery attacks implies that the MAC algorithm should be both 
one-way and collision resistant for someone who does not know the secret key 
K. This definition leaves the problem open whether or not a MAC algorithm 
should be one-way or collision resistant for someone who knows K. An example 
where this property could be useful is the authentication of multi-destination 
messages wm- 



4.4 Applications of Cryptographic Hash Functions 

Cryptographic hash functions can be used to provide for information authenti- 
cation with and without secrecy. It will also be shown that hash functions play 
a very important role in the design of digital signature schemes. Other applica- 
tions that will not be discussed here are the protection of pass-phrases (probably 
the first application of one-way functions), the commitment to a string without 
revealing it key derivation, and the construction of block ciphers. 



Authentication without Secrecy. In this case there is only a plaintext avail- 
able, which significantly reduces the number of options. 

MAC. In order to protect the authenticity of the information, one computes the 
MAC and appends it to the information. The authenticity of the information now 
depends on the secrecy and authenticity of the secret key and can be protected 
and verified by anyone who is privy to this key. The protection of authenticity 
has thus been reduced to the problem of securely establishing shared keys. This 
approach can against outsider attacks, as all parties involved have the same 
capabilities and hence should trust each other. 

The scheme can be made even more secure (but less practical) if also the au- 
thenticity and/or secrecy of the MAC of every plaintext is protected. A possible 
implementation could consist of an exchange of messages over a high speed com- 
munication link, while the corresponding MACs are sent over a slower channel, 
which protects authenticity and/or secrecy. For a strong MAC algorithm, this 
additional protection is not necessary. 

MDC. If an MDC is used, authenticity of the information is transferred to the 
authenticity of a string of fixed length. The advantage over a MAC is that there 
is no need for management of secret keys. In exchange for this, an authentic 
channel has to be provided for every MDC. This means that the capacity of the 
channel will increase with the number of messages. Although the lifetime of a 
key is also related to the number of times it has been used, it is clear that the 
authentic channel for the MDC will need a significantly greater capacity than 
the channel that protects both authenticity and secrecy of the key for a MAC. 
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Just as for a MAC, the parties that use this approach are supposed to trust 
each other, but it is important to consider what will happen if a dispute arises, 
or what will happen if an insider attacks the system. An insider will try to find 
a collision, i.e., two plaintexts X and X' such that h{X) = h{X'). Subsequently 
he will protect the authenticity of X through h{X), but at any time later he 
will be able to substitute X' for X. In order to avoid this attack, h should be a 
CRHF. 

However, one can certainly imagine applications where this attack is not 
relevant. In that case one only has to be protected against outsiders, hence it 
suffices that h is a OWHF: an outsider cannot select X, but will only be able 
to observe X and h{X) and subsequently try to come up with an X' such that 
h{X) = h{X'). 

1. The parties involved completely trust each other, which is trivially the case 
if there is only one party. One could think of someone who protects the 
integrity of his computer files through the calculation of an MDC that he 
stores in printed form in this vault. Every day he can repeat the calculation 
and verify the result. 

2. The computation of the h{X) involves a random component, that cannot 
be controlled by the insider (see Merkle mg and Damgard m) : X can be 
randomized before applying h through encryption of X with a good block 
cipher using a truly random key, that is added to the resulting ciphertext 
Eng, or through the selection of a short random prefix to X iDJ; h itself 
can be randomized through randomly choosing h from a family of functions 
indexed by a certain parameter (a UOWH as defined by Naor and Yung 

cf. Sect. 

The advantage of a OWHF is that its design is easier and that storage for 
the hash result can be halved (64. . . 80 bits instead of 128. . . 160 bits). How- 
ever, note that the result cannot be too small as the security level degrades 
proportional to the number of applications of h: an outsider who can attack 
a set {h{X) \ X G Domain(h)} of size s has increased his probability to find 
an X' with a factor s. This limitation can be overcome through the use of a 
parameterized OWHF. 

Note that one could also consider to encrypt an MDC in order to obtain a 
MAC (for example, [1 6,'I| p. 622]). In this case the hash function has to be a 
CRHF, since a collision allows for a forgery after one chosen text. This approach 
imposes strong conditions on the encryption algorithm as well; for example, an 
additive stream cipher would obviously be insecure. For a block cipher in CBC 
mode, the security level is limited by the block size (the IV can be used to 
manipulate the first ciphertext block). If the encryption algorithm (with the 
same key) is also used for encryption of plaintext, this solution is problematic, 
as a chosen text attack on the encryption scheme leads directly to a forgery of 
the MAC. In conclusion, this approach cannot be recommended as a general 
solution, as it abuses a primitive for secrecy to a primitive for authentication. 
A discussion of a related scheme (the secret suffix method) can be found in 
Sect. M :z\ 
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Authentication with Secrecy. If both authentication and secrecy are pro- 
tected, the overall system can sometimes be simplified. For insider attacks, the 
additional encryption makes no difference, as an insider knows the secret key 
for the encryption. This means that for certain applications it should be hard 
to find collisions. For an outsider, an attack on the scheme becomes in general 
harder, as his knowledge decreases. 

Although it is tempting to use this fact to lower the requirements imposed 
on the hash functions, this is certainly not a good practice. The additional pro- 
tection offered by the encryption is dependent on the strength of the encryption 
algorithm and on the mode in which it is used. 

MAC. Several options can be considered, but all share the problem of a double 
key management: one for the authentication and one for the encryption. They 
also require two passes over the message. It is tempting to use the same key 
twice, but this has to be discouraged strongly: not only are there dangerous 
interactions possible between the encryption scheme and the MAC algorithm, 
but the management of both keys should be different (e.g., lifetime, storage 
after use); finally, one risks that one application compromises the other one. 
The advantage of this approach is a high security level, owing to the complete 
separation of protection of privacy and authentication. 

The most straightforward option is to calculate the MAC, append it to the 
information and subsequently encrypt the resulting message. This has the ad- 
vantage that it precludes a direct exhaustive key search on the MAC key. An 
alternative is to omit the encryption of the MAC. The third solution is to cal- 
culate the MAC on the enciphered message; it has the advantage is that the 
authenticity can be verified without knowing the plaintext or the secret key of 
the encryption algorithm. This can be useful in the context of key management, 
but it is often preferable to protect the authenticity of the plaintext instead of 
the authenticity of the ciphertext. Recently Jakubowski and Venkatesan have 
provided a security proof for a construction that combines a simplified MAC 
algorithm with an additive stream cipher m, 

MDC. The advantages for using an MDC are a ‘light weight’ key management 
(only one key is required) and the fact that the authentication is derived directly 
from the privacy protection. Integrity and confidentiality can be protected at dif- 
ferent layers in the communication protocol stack; no secret information is nec- 
essary at the (higher) layer that calculates the MDC. The disadvantage is that 
the protection of authenticity depends on the privacy protection: if the encryp- 
tion algorithm is weak, the protection of authenticity will also be jeopardized. A 
second, more serious disadvantage is that such a solution is not acceptable with 
most standard encryption modes. If the MDC is calculated on the plaintext, and 
appended as the last block before the encryption, the following observations can 
be made: 

— If the encryption algorithm is an additive stream cipher where the opponent 

knows the plaintext, an attack by Jueneman applies: an attacker can 
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easily compute the key-stream sequence. Subsequently he can modify the 
plaintext, calculate the MDC, and encrypt both the new plaintext and the 
new MDC. This attack is independent of the choice of the MDC. A solution 
suggested by Jueneman is to let the MDC depend on a random initial value 
IV , that depends on the previous message in the session. This approach is 
limited to session-based communications. 

— Even if the encryption algorithm provides some error propagation, such as 
the CBC-mode of a block cipher, the scheme is vulnerable (this attack has 
been pointed out by D. Wagner): consider the plaintext Ar||MDC(Ar)||y, 
where Y falls on a block boundary, and || denotes concatenation. An op- 
ponent who obtains the corresponding ciphertext can chop of the blocks 
corresponding to Y and to the MDC on the plaintext, and obtain the ci- 
phertext of an ‘authentic’ plaintext that was never sent (namely X). This 
particular attack can be precluded by prepending the length of the input. 
Randomization of the plaintext will not preclude this attack. A solution 
would be a very strong encryption mode, where every bit of the ciphertext 
depends in a complex way on every bit of the plaintext (for example the 
package transform of Rivest cna). Simple variations of the CBC mode, 
such as the PCBC mode (which was used in Kerberos v4) are not sufficient. 

Note that if the MDC is not encrypted, it will leak information. For example, 
anyone can verify whether the plaintext belongs to a small list of plaintexts, 
which is an undesirable property. 

Because of the weaknesses pointed out, this solution is not recommended as a 
generic solution. Moreover, for large messages the unconditionally secure MACs 
(cf. Sect, d are more secure and faster than MDCs. The method should only 
be used in applications which cannot afford two independent strong operations. 
In that case some performance could be gained by using a function with weaker 
properties than an MDC; but is has been pointed that simple additions are not 
sufficient (see csa for examples). 

5 An Overview of MDC Proposals 

First a general model is presented for iterated hash functions. Next four types 
of MDCs are briefly discussed: MDCs based on a block cipher, MDCs based on 
algebraic structures (modular arithmetic, knapsack, and lattice problems), and 
custom designed MDCs. For a more detailed discussion, the reader is referred 
to |1 ,‘I4IJ . The performance in software of MDCs based on a block ciphers and 
custom designed hash functions is discussed by Preneel et al. in [ng. 

5.1 A General Model for Iterated Hash Functions 

Before discussing a selection of the dozens of proposed MDCs, a general scheme 
for describing a hash function will be presented. Most known hash functions are 
based on a compression function with fixed size input; they process every message 



68 



Bart Preneel 



block in a similar way. Lai and Massey call this an “iterated” hash function unzi. 
The information is divided into t blocks Xi through Xt- If the total number of 
bits is not a multiple of the block length, the information is padded to the 
required length (using a so-called padding rule). The hash function can then be 
described as follows: 



Ho = IV 

H, = f{X,,H,_i) i = l,2,...t 
h{X) = g{Ht) . 

The result of the hash function is denoted with h{X) and IV is the abbreviation 
for Initial Value. The function / is called the round function or compression 
function, and the function g is called the output transformation. It is often 
omitted (that is, g is often the identity function). Two elements in this definition 
have an important influence on the security of a hash function: the choice of the 
padding rule and the choice of the IV. It is recommended that the padding rule 
is unambiguous (i.e., there do not exist two messages that can be padded to the 
same padded message); at the end one should append the length of the message; 
and the IV should be defined as part of the description of the hash function 
(this is called MD-strengthening after Merkle and Damgard) . In some cases one 
can deviate from this rule, but this will make the hash function less secure and 
may lead to trivial collisions or second preimages. 

Research on hash functions has been focussed on the question: which prop- 
erties should be imposed on / to guarantee that h satisfies certain properties? 
Two partial answers have been found to this question. The first result is by Lai 
and Massey nnn and gives necessary and sufficient conditions for / in order to 
obtain an “ideally secure” hash function h. 

Theorem 1 (Lai— Massey) . Assume that the padding contains the length of the 
input string, and that the message X (without padding) contains at least 2 blocks. 
Then finding a second preimage for h with a fixed IV requires 2” operations if 
and only if finding a second preimage for f with arbitrarily chosen requires 
2" operations. 

The fact that the condition is necessary is based on the following argument: if 
one can find a second preimage for / in 2® operations (with s < n), one can 
find a second preimage for h in operations with a meet-in-the-middle 

attack (cf. Sect. Vo.'Zi . 

A second result by Damgard m and independently by Merkle mg states 
that for to be a CRHF it is sufficient that / is a collision resistant function. 

Theorem 2 (Damgard— Merkle). Let f be a collision resistant function map- 
ping I to n bits (with I — n > 1). If an unambiguous padding rule is used, the 
following construction yields a CRHF: 



Hi = /(0"+i li Ai) 

H, = f{H,_i\\l\\X,) fori = 2,3,...t. 
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The construction can be improved slightly, and extended to the case where I = 
n + 1, at the cost of an additional assumption on / (see m for details and 
Gibson’s comment in cm). It can also extended to a tree construction, which 
allows for increased parallelism M- 



5.2 MDGs Based on a Block Cipher 

Several arguments can be indicated for designers of hash functions to base their 
schemes on existing encryption algorithms. The first argument is purely histor- 
ical: DES |6 1] was the first standard commercial cryptographic primitive that 
was widely available; it seemed natural to construct hash functions based on this 
block cipher. A second argument is the minimization of the design and imple- 
mentation effort: hash functions and block ciphers that are both efficient and 
secure are hard to design, and many examples that support this view can be 
found in the literature. Moreover, existing software and hardware implementa- 
tions can be reused, which will decrease the cost. The major advantage however 
is that the trust in existing encryption algorithms can be transferred to a hash 
function. The main disadvantage of this approach is that custom designed hash 
functions are likely to be more efficient. This is particularly true because hash 
functions based on block ciphers require a key change after every encryption. 
Finally note that block ciphers may exhibit some weaknesses that are only im- 
portant if they are used in a hashing mode (cf. Sect. 16.41) . One also has to take 
into account that in some countries export restrictions for block ciphers may be 
tighter than those for hash functions. 

The encryption operation E will be written as F = Ex{X). Here X denotes 
the plaintext, Y the ciphertext, and K the key. The corresponding decryption 
operation D is written as X = Dx{Y). The size of the plaintext and ciphertext 
or the block length (in bits) will be denoted with r, while the key size (in bits) 
will be denoted with k. In the case of the well known block cipher DES, r = 64 
and fc = 56 m- The hash rate of a hash function based on a block cipher is 
defined as the number of r-bit input blocks that can be processed with a single 
encryption. 

A distinction will be made between the cases n = r, n = 2 ■ r, and n > 2r. 
This is motivated by the fact that most proposed block ciphers have a block 
length of only 64 bits, and hence an MDC with a result at least twice the block 
length is necessary to obtain a CRHF. Other proposals are based on a block 
cipher with a large key. Finally some related constructions are briefly discussed. 



Size of Hash Result Equal to the Block Length. From Definition □ it 
follows that these hash functions can only be collision resistant if the block 
length r is at least 128 bits to 160 bits. Most present day block ciphers have 
only a block length of 64 bits, but the AES (Advanced Encryption Standard,) 
which NIST intends to publish by the year 2000, will have a block length of 128 
bits. 
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All schemes of this type have rate 1. The first secure construction for such a 
hash function was the ’85 scheme by Matyas et al. da: 

Here s() is a mapping from the ciphertext space to the key space and E®{X) 
denotes Ek{X)(BX . This is the main building block for all hash functions based 
on block ciphers. It is widely believed that this mapping is hard to invert, but 
there is no proof of this. One can apply the following intuitive reasoning: either 
one chooses the plaintext X, but then one has to find the key corresponding to 
one plaintext/ciphertext pair, which is deemed to be infeasible; alternatively, one 
chooses the key, but then one has to find for a given key a plaintext/ciphertext 
pair with a known difference, which is also believed to be difficult. This gen- 
eral construction is also used in several custom designed hash functions (cf. 
Sect. 15.41) . This scheme has been included in ISO/IEC 10118-2 A variant 
on this scheme was proposed in 1989 independently by Preneel et al. and 
by Miyaguchi et al. inn for N-hash and later for any block cipher inn. 

Preneel et al. show that 12 secure variants exist, that are obtained by applying 
an affine transformation to the inputs of the two schemes above csa. Moreover, 
the security level of these hash functions is limited by min(/c, r), even if the size 
of some internal variables is equal to max(A:,r). These variants have slightly 
different properties related to weak keys, the complementation property, and 
differential attacks (cf. Sect. EJ- It is conjectured that for these schemes based 
on an ‘ideal’ block cipher (a random one-way permutation) no shortcut attacks 
exist, which implies that a collision attack requires about 2’'/^ operations and a 
preimage attack about 2’' operations. 

An important variant of the first scheme is widely known as the Davies-Meyer 
scheme (the real inventors are probably Matyas and Meyer): 

Tl, = A® (H,_i). (2) 

It has the advantage that it extends more easily to block ciphers where key size 
and block size are different. 



Size of Hash Result Equal to Twice the Block Length. The goal of 
double block length hash functions is to achieve a higher security level against 
collision attacks. Ideally a collision attack on such a hash function should require 
2'" operations, and a (2nd) preimage attack 2^’’ operations. 

A series of proposals attempted to double the size of the hash result, for 
example by iterating a OWHF; all of these succumbed to a ‘divide and conquer’ 
attack. A large class of proposals of rate 1 has the following form: 
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where Aj, B], and C] are binary linear combinations of and 

X"^ and where A^, Bf, and Cf are binary linear combinations of Xf, 

Xf, and Hi . The hash result is equal to the concatenation of Hi and Hf. First 
it was shown by Hohl et al. that the security level of the compression function of 
these hash functions is at most that of a single block length hash function m 
Next Knudsen et al. showed that for all hash functions in this class, a preimage 
attack requires at most 2’' operations, and a collision attack requires at most 
operations (for most schemes this can be reduced to 2’'/^) IIOII . 

The few proposals that survive till today have rate less than 1. Two important 
examples are MDC-2 and MDC-4 with hash rate 1/2 and 1/4 respectively. They 
have been designed by Bracht et al. El, and are also known as the Meyer- 
Schilling hash functions after the authors of the first paper describing these 
schemes 1 1 'Z2\ . MDC-2 has been included in ISO/IEC 10118-2 (iii ^ more 
general form); it can be described as follows: The variables H^ and Hq are 
initialized with the 

= Km = LTl II RTl Hi = LTl II RTl 

= KhU ) II II ■ 

values IV\ and IV 2 respectively, and the hash result is equal to the concatenation 
of Hi and Hf. The ISO/IEC standard does not specify the block cipher; it 
also requires the specification of two mappings u, v from the ciphertext space 
to the key space such that u{IV^) ^ v{IV^). For DES, these mappings from 
64 to 56 bits drop the parity bits in every byte and fix the second and third 
key bits to 01 and 10 respectively (to preclude attacks based on (semi-)weak 
keys). The best known preimage and collision attacks on MDC-2 require 2^’' 
and 2’’ operations respectively Ena. A collision attack on MDC-2 based on DES 
(r = 64, k = 56) requires at most 2®^ encryptions. However, it is obvious that the 
compression function of MDC-2 is rather weak: preimage and collision attacks 
on the compression function require at most 2’' and 2’’/^ operations (one fixes 
Xi and varies Hl_^ and Hf_^ independently). 

One iteration of MDC-4 consists of the concatenation of two MDC-2 steps, 
where the plaintexts in the second step are equal to H2i-i and Hli-i. The 
rate of MDC-4 is equal to 1/4. The best known attack to find a preimage for 
MDC-4 requires 2^’' operations. This shows that MDC-4 is probably more secure 
than MDC-2 against preimage attacks. However, a collision for the compression 
function of MDC-2 with a specified value for Hl_^ and H^_^ also yields a collision 
for the compression function of MDC-4. Moreover, it has been demonstrated in 
by Preneel and Knudsen that collisions for the compression function 

of MDC-4 can be found with encryptions and the storage of r-bit 
quantities. 

Merkle describes an interesting proposal in m for which he can prove that 
the compression function is collision resistant based on the assumption that the 
underlying single block length scheme is secure. The simplest scheme (with rate 
1/18.3 for DES) can be described as follows: 
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Hi = chopig i;®. 



'16 




Here is a string consisting of 112 bits, the leftmost 55 bits of which are 
denoted H/_i, and the remaining 57 are denoted Hf_i, Xi consists of 7 bits only. 
The function chop^ drops the r rightmost bits of its argument. Note that this 
construction is similar to MDC-2 (but much slower). The most efficient proposal 
is more complex and use six invocations of the block cipher in two layers. Its 
hash rate is equal to 0.27 for DES. Merkle’s proof for this proposal only showed 
a security level of 2^^ ® against collisions; Preneel has improved this to 2®® 1 1 ,'14] . 

Even the schemes in this class that provide optimal security do not offer long 
term collision resistance when used with DES; this will change with AES, which 
will have a block and key length of 128 bits (key lengths of 192 and 256 bits will 
also be provided). 

Size of Hash Result Larger than Twice the Block Length. Knudsen and 
Preneel also design a collision resistant compression function, but with paral- 
lel encryptions only nn2|. They show how a class of efficient constructions for 
hash functions can be obtained by using non-binary error-correcting codes. Their 
schemes can achieve a provable security level against collisions equal to 2’', 

(or more) and this with rates larger than 1/2; the security proof reduces the 
security of this scheme to an assumption on the single block length hash func- 
tions. The internal memory of the scheme is however much larger than 2 or 3 
blocks, which implies that an output transformation is required. Earlier work by 
Preneel et al. unnj followed a related approach, but was not based on a collision 
resistant compression function. 

Size of the Key Equal to Twice the Block Length. Some block ciphers 
have been proposed for which the key size is approximately twice the block 
length. One well known example is IDEA . The AES variant with a 256-bit 
key also belongs to this class. It is not recommended to use triple DES with 2 
keys here; one can exploit the structure in the triple DES key schedule. 

Size of the Hash Result Equal to the Block Length. A scheme in this class was 
proposed by Merkle in HE| in ’79, who observed that a block cipher with key 
size larger than block size is a natural compression function: 



with C a constant string. An alternative scheme was suggested by Lai and Massey 



These constructions can only yield a CRHF if the block length is larger than 128 
bits (Merkle suggested 100 bits in 1979), and if the key size sufficiently large. 
For smaller block lengths, a OWHF can be obtained. 



Hi — Eh._^ II Xi(C') : 



cnil: 



Hi — II Xi{Hi-i) . 
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Size of the Hash Result Equal to Twice the Block Length. In order to obtain 
a CRHF based on a 64-bit block cipher, a different construction is required. 
The first two schemes in this class were proposed by Lai and Massey |1 i)7| . Both 
extend the Davies-Meyer scheme. One scheme is called “Tandem Davies-Meyer,” 
and has the following description: 

Hi = 

The second scheme is called “Abreast Davies-Meyer”: 

Hi = 

Hf = , 

Here H denotes the bitwise complement of H. Both schemes have rate equal 
to 1/2; the best known attacks for a preimage and a collision requires 2^” re- 
spectively 2” encryptions. Faster schemes in this class have been developed in 

m- 



Related Schemes. Aiello and Venkatesan propose in 0 a construction to 
double the output of a random function. In order for it to be usable for hashing, 
one needs to define the key schedule of this larger ‘block cipher’. The construction 
by Aiello, Haber, and Venkatesan |3 replaces the key schedule of DES by a 
function from the MDx-family (cf. Sect. 15. 4|) : several instances are combined by 
choosing different (fixed) plaintexts. 

5.3 MDCs Based on Algebraic Structures 

First hash functions based on modular arithmetic are considered. Next hash 
functions based on knapsack problems and lattices are presented. This section 
is concluded with a short discussion of incremental hash functions. 

MDCs Based on Modular Arithmetic. These hash functions are designed 
to use the modular arithmetic hardware that is required to produce digital sig- 
natures (for example, RSA j I .‘t.'-ij ) . The security of certain constructions can 
be based on the hardness of some number theoretic problems. Moreover these 
schemes are easily scalable. The disadvantage is that the underlying primitive 
has a rich mathematical structure; this can be exploited in attacks that use the 
homomorphic structure and the fixed points of modular exponentiation (trivial 
examples are 0 and 1); one also has to ensure that no small inputs occur. 

A distinction is made between ‘ad hoc’ schemes, which have no provable 
reduction to the underlying hard problem, and provably secure schemes. Schemes 
in the first class are typically much more efficient, but many proposals have been 
broken; however, it seems that recently designers have been more conservative 
and designs survive longer. 
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Schemes Without Security Reduction. Most of these schemes uses a modulus iV, 
that is, the product of two large primes. The size of N in bits (denoted with 
n) is typically between 512 and 1024. These hash functions can be useful in 
combination with RSA unni as digital signature scheme. However, this choice 
poses the following practical problem: the person who has generated the modulus 
knows its factorization, and hence he has a potential advantage over the other 
users of the hash function. One can try to design the hash function such that 
knowledge of the factorization does not help in attacking it (this is probably 
difficult to achieve). Alternatives are to use a trusted third party to generate 
the modulus (for example, the modulus of the Certification Authority), or to 
generate the modulus using a multi-party secure computation; recently practical 
solutions for such a computation have been developed by Boneh and Franklin 
m and Frankel et al. m- 

The most efficient schemes are based on modular squaring. An additional 
argument for squaring is that any algorithm that can extract modular square 
roots is reducible to a factoring algorithm (in random polynomial time). One 
approach is to study all possible schemes that use a single squaring and exclusive 
ors and that have an internal memory of only one block. The best scheme in 
this class seems to be of the form: Hi = {Xi 0F7i_i)^ mod N © The 

introduction of the feedforward offers certainly advantages over the CBC-mode, 
which can be found in many earlier proposals. 

It is essential to add redundancy to the message input. However, Girault [zg 
and Girault and Misarsky have pointed out that early proposals to insert a 
fixed pattern (for example, zeroes in the beginning, middle, or end) are insecure. 
This has resulted in dispersing the redundancy to the most significant nibble 
(4 bits) of every byte. This proposal made it to the informative annex D of 
GGITT-X. 509:1989 |^. Goppersmith showed however that one can construct 
two messages such that their hash results are a multiple of each other . If the 
hash function is combined with a multiplicative signature scheme like RSA cna, 
one can exploit this attack to forge signatures. As a consequence, new methods 
for adding redundancy were proposed within ISO/IEG SG27. The current version 
of the Final Draft International Standard (FDIS) is called MASH-1 (for Modular 
Arithmetic Secure Hash) pH] : 



= Af (modA^) © 

here A — OxFOO . . . 00, the four most significant bits in every byte of Xi are set to 
1111, and the output of the squaring operation is chopped to n bits. A complex 
output transformation is added, which consists of a number of applications of 
the compression function; its goal is to destroy all the remaining mathematical 
structure. The final result is at most n/2 bits. The best known preimage and 
collision attacks on MASH-1 require 2”/^ and 2”/^ operations; they are thus not 
better than brute force attacks. 

Stronger schemes have been proposed that are slower. Examples are the use of 
two squaring operations m- f = [Hi-i © (Ai)^) mod N, and the replacement 
of the squaring by a higher exponent (typically 3 ...2^® + 1). For example. 
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MASH-2 is a variant of MASH-1 which uses exponent 2® -|- 1 ^3- This provides 
for an additional security margin. 

Schemes With a Security Reduction. For several schemes there exists a security 
reduction to a number theoretic problem that is believe to be difficult. However, 
they are very slow: typically they hash log 2 log 2 N bits per modular squaring (or 
even per modular exponentiation). 

Damgard provides two hash functions for which finding a collision is provably 
equivalent to factoring an RSA modulus m- Gibson proposes a construction 
based on the discrete logarithm problem modulo a composite EH- A third ap- 
proach uses the discrete logarithm problem in a group of prime order p denoted 
with Gp (Bellare et al. after earlier work by Chaum et al. m and Brands). 
Every non-trivial element of Gp is a generator. The hash function uses t random 
elements ai from Gp (at yf 1). The hash result is then computed as 

i=l 

Here Xi is obtained by considering the string Xi as the binary expansion of a 
number and prepending 1 to it. This avoids trivial collisions when Xi consists 
of all zeroes. 



MDGs Based on Knapsack and Lattice Problems. The knapsack problem 
(which is a special case of the subset sum problem) of dimensions n and £(n) 
can be defined as follows: given a set of n Z-bit integers {ai, 02 , ... , o„}, and an 
integer S, find a vector X with components Xi equal to 0 or 1 such that 

n 

ai - Xi = S mod 2^^"^ . 

i=l 

For application to hashing, one needs n > £{n). The knapsack problem is known 
to be NP-hard; while this means that probably no feasible worst-case algorithms 
for this problem exists, this does not tell much about the hardness of a random 
instance. This problem was used in 1978 by Merkle and Heilman to construct the 
first public-key encryption system P2D|. However, almost all public key schemes 
based on the knapsack problem have been broken (see for example H2ni), which 
has given the knapsack a bad reputation. The appeal of the knapsack problem 
(and related lattice based problems) lies in the fact that both hardware and 
software implementations are very fast compared to schemes based on number 
theoretic problems. Moreover, evaluation of a knapsack allows for significant 
parallelism. Finally, interesting security reductions can be proved: examples are 
the work for Impagliazzo and Naor [S3 on knapsacks and that of Ajtai [01 for 
lattices; Ajtai was able to prove that if the shortest vector in a lattice problem is 
hard in the worst case, then the knapsack problem is hard on the average. How- 
ever, some researchers believe that for realistic parameters, both these problems 
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are relatively easy. If they are right, knapsack and lattice problems are not useful 
to practical cryptography. 

Attacks on knapsacks often use the LLL lattice reduction algorithm miBi that 
finds the shortest vector in a lattice (the algorithm performs in practice much 
better than can be guaranteed). This reduction to the shortest vector problem 
only works for £(n) > 1.0629 -n. Knapsack problems become more difficult when 
n K, i(n); however, the performance of the hash function decreases with the 
value n — i{n). For n = t'(n), the best known attack requires time 0(2"/^) and 
space 0(2”/^). Impagliazzo and Naor summarize the state of the art in m 
A different class of attacks are the algebraic attacks proposed by Camion and 
Patarin m and optimized by Patarin in Hn2]; these attacks tend to work better 
when n 3> £{n). The scheme of Damgard has been broken both using LLL 

and using algebraic techniques It is for the time being an open problem 
whether a random knapsack with n = 1024, I = 512, and £ = 512 is hard to 
solve. 

Impagliazzo and Naor describe an efficient construction for a UOWHF (cf. 
Sect . tl.2ll and provide a reduction of its security to that of the knapsack problem 
|tS4l |. Ajtai introduced a function that is one-way (or preimage resistant) if the 
problem of approximating the shortest vector in a lattice to polynomial factors 
is hard |n|. Goldreich et al. have proved that the function is in fact collision 
resistant. 

Several multiplicative knapsacks have also been proposed; multiplicative no- 
tation is used for non-abelian groups. The earliest proposal dates back to ’77 
(but it was quickly shown to be insecure) . A recent example are the schemes by 
Zemor imi and Tillich and Zemor unsi. Their security is based on the hardness 
of finding short factorizations in certain groups. In some cases one can even prove 
a lower bound on the Hamming distance between colliding messages. Attacks on 
these proposals (for certain parameters) can be found in |,4 Il6t)j . Impagliazzo and 
Naor also extend their construction on a UOWHF to multiplication in a group 

Knapsack and lattice based hash functions have also the potential problem 
that trapdoors may be inserted when the vectors are generated. Therefore it is 
recommended that the instance generation is reproducible (for example, through 
the use of a pseudo-random string generator or a hash function). 



Incremental Hash Fhnctions. A hash function (or any cryptographic primi- 
tive) is called incremental if it has the following property: if the hash function has 
been evaluated for an input x, and a small modification is made to x, resulting 
in x' , then one can update h{x) in time proportional to the amount of modifica- 
tion between x and x', rather than having to recompute h(x') from scratch. If a 
function is incremental, it is automatically parallelizable as well. 

This concept was first introduced by Bellare et al. H2|. They also made 
a first proposal based on exponentiation in a group of prime order. Improved 
constructions were proposed by Bellare and Micciancio dSI that consist of two 
steps: 
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— First the message is divided into blocks; each block (together with its in- 
dex) is hashed using a conventional hash function (restricted to fixed length 
inputs). This is called the ‘randomization’ step as in the analysis the hash 
function is treated as an ‘ideal’ hash function or random oracle (which is a 
very demanding requirement). 

— Next the different outputs are combined using a group operation. This can 
be a group of large prime order in which the discrete logarithm problem 
is hard, and modular addition. The first approach leads to a reduction to 
the discrete logarithm problem, while the second leads to a reduction to the 
‘weighted knapsack’ problem. 

The same techniques can also be used to improve the lattice based hash function. 
These schemes have the advantage that they are much more efficient than the 
other schemes studied in this section. However, this comes at a cost of requiring 
a collision resistant hash function, which also has to behave ‘perfectly random.’ 
This construction is remarkable, as it construct a collision resistant function 
based on a one-way property (but with specific algebraic structure, so there is 
no contradiction to the result of Simon HM) discussed at the end of Sect. l,'I.2li . 



5.4 Custom Designed MDCs 

This section discusses a selection of custom designed hash functions, i.e., al- 
gorithms that were especially designed for hashing operations. Most of these 
algorithms use the Davies-Meyer approach (cf. Sect. 11.211 : the compression func- 
tion is a block cipher, ‘keyed’ by the text input Xi\ the plaintext is the value 
Hi-i, which is also added to the ciphertext (feedforward). 

MD2 j2Bl is a hash function with a 128-bit result that was published by 
Rivest of RSA Data Security Inc. in 1990. The algorithm is software oriented, 
but due to the byte structure it is not very fast on 32-bit machines. It inserts at 
the end a checksum byte (a weak hash function) of all the inputs. Rogier and 
Chauvaud find collisions for a variant of MD2, that omits the checksum byte at 
the end cna. 

A much faster algorithm by the same designer is MD4 [ins; it also dates 
back to 1990 and has a 128-bit result. The main merit of the algorithm is that it 
introduces innovative design principles; the most important one is the use of 32- 
bit integer arithmetic. The algorithms derived from it (with improved strength) 
are often called the MDx-family. This family contains the most popular hash 
functions in use today. Dobbertin has found collisions for MD4; his attack com- 
bines algebraic techniques and optimization techniques such as genetic algo- 
rithms ISIE2]. It can be extended in such a way that even ‘meaningful’ collision 
are obtained: the complete message (except for a few dozen bytes) is under com- 
plete control of the attacker. His attack also applies to the compression function 
of ‘extended MD4’ [1 .10) . which consists of concatenating two loosely coupled 
instances of MD4. Later Dobbertin showed that a reduced version of MD4 (2 
rounds out of 3) is not preimage resistant |S3|. 
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Following early attacks on MD4 by Merkle and den Boer and Bosselaers mi, 
Rivest quickly proposed a strengthened version, namely MD5 m- It was how- 
ever shown by den Boer and Bosselaers m that the compression function of 
MD5 is not collision resistant (but their collisions are of the form f{Hi-i,Xi) = 
which is not immediately usable in practice). Dobbertin has ex- 
tended his attack on MD4 to yield collisions for the compression function of 
MD5, i.e., f{Hi-i,Xi) = /(i?i_i,X'), where he has some control over Hi-i 
It is believed that it is feasible to extend this attack to collisions for MD5 
itself (that is, to take into account the IV). HAVAL was proposed by Zheng, 
Pieprzyk, and Seberry at Auscrypt’92 inni; it consists of several variants, and 
is an extension of MD5. 

A second improved variant of MD4, the Secure Hash Algorithm, was proposed 
by NIST mi 1993. The size of the hash result is increased from 128 to 160 bits 
and the message words are not simply permuted but encoded with a shortened 
cyclic code. After a few years, NSA discovered a certificational weakness in SHA; 
apparently collisions can be found in less than 2®° operations. Consequently a 
new release of the standard was published. The new algorithm is called SHA-1 
pg. Recently Chabaud and Joux have published an attack that finds collisions 
for SHA in 2®^ operations PQ]; it is probably similar to the (classified) attack 
developed earlier that prompted the upgrade to SHA-1. 

Yet another improved version of MD4, called RIPEMD, was developed in 
the framework of the EEC- RACE project RIPE |149| . Due to partial attacks by 
Dobbertin m, it was later upgraded by Dobbertin et al. to RIPEMD-128 and 
RIPEMD-160, that have a 128-bit and a 160-bit result respectively m|. Variants 
with a 256 and 320-bit result have been introduced as well. Together with SHA- 
1, RIPEMD-128 and RIPEMD-160 are the three custom designed hash functions 
included in ISO/IEC 10118-3 PO]- 

N-hash is a hash function designed by Miyaguchi et al. den Boer 

(unpublished) and Biham and Shamir [ I Dj have identified serious weaknesses in 
this scheme. A new version of N-hash appeared in a Japanese contribution to 
ISO pg. It was shown that this scheme contains additional weaknesses 1 1 81 1 ;-14j . 

Schnorr and Vaudenay propose in ung FFT-Hash HI; as the name suggests, 
Schnorr has made some earlier designs that were shown to be weak. No weak- 
nesses have been reported for FFT-Hash HI. 

Merkle suggested in 1989 a software oriented one-way hash function called 
Snefru 11191 . It is based on large random substitution tables (2 Kbyte per pass) 
and allows for a variable size of the result (128 or 256 bits). Biham and Shamir 
have shown that Snefru-128 m is vulnerable to differential attacks. As a con- 
sequence it is recommended to use 6 and preferably 8 passes, preferably with a 
256-bit hash result. However, these measures increase the size of the substitution 
tables and decrease the performance H3B|. 

Two of the most recent designs are Tiger and Panama. Tiger was proposed 
by Anderson and Biham [ 7 ]. It is tuned towards 64-bit processors and mixes 
Snefru-type S-boxes (8 input bits and 64 output bits) with arithmetic operations. 
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Panama is a design of Daemen and Clapp m-, it is designed to take advantage 
of the instruction-level parallelism in modern processors. 

The scheme by Damgard m based on a cellular automaton was broken by 
Daemen et al. in m- In the same paper these authors have proposed Cellhash, a 
new hash function based on a cellular automaton m- Later an improved version 
called Subhash was published m Both schemes are hardware oriented. 

6 Methods of Attack on MDCs 

This section gives an overview of the known methods of attack on MDCs. This 
taxonomy can be helpful to understand the attacks published in the literature, 
but can also serve as a caveat for designers or evaluators. From these attacks, 
one can conclude that one should take a conservative approach. This implies that 
if one can find ‘randomly looking’ collisions or second preimages for an MDC, 
one should anticipate that a further refinement or optimization of the attack can 
find collisions or second preimages that satisfy additional constraints. 



6.1 Attacks Independent of the Algorithm 

These attacks depend only on the size n in bits of the hash result, and are 
independent of the specific details of the algorithm. It is assumed that the MDC 
approximates a random function: if this is not the case this class of attacks will 
be even more successful. For the time being 2®^ operations is considered to be 
on the edge of feasibility. In view of the fact that the speed of computers is 
multiplied by four every three years (this is one of the formulations of Moore’s 
law), 2^® operations is sufficient for the next 5 to 10 years, but it will be only 
marginally secure within 15 years. For applications that require protection for 
20 years, one should try to design the scheme such that an attack requires at 
least 2®® operations. 



Random (2nd) Preimage Attack. The opponent selects a random message 
and hopes that a given hash result will be hit. If the hash function has the 
required “random” behavior, his probability of success equals 1/2" with n the 
number of bits of the hash result. This attack can be carried out off-line and in 
parallel, which means that n should be at least 64. If a significant number of 
messages can be attacked simultaneously, it is advisable to select a larger value 
of n. 



Birthday Attack. The birthday paradox states that for a group of 23 people, 
the probability that at least two people have a common birthday exceeds 1/2. 
Intuitively one expects that the probability is much lower. However, the number 
of pairs of people in such a group equals 23 • 22/2 = 253. This can be exploited to 
attack a hash function in the following way: an adversary generates r\ variations 
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on a bogus message and r 2 variations on a genuine message. The expected num- 
ber of collisions equals ri • r<ijn. The probability of finding a bogus message and 
a genuine message that hash to the same result is given by 1 — exp(— ri • r 2 / 2 "), 
which is about 63% when r = ri = r 2 = 2?. Finding the collision does not re- 
quire operations: after sorting the data, which requires 0(r log r) operations, 
comparison is easy. This attack was first pointed out by Yuval nra . 

One can reduce the memory requirements for collision search by translating 
the problem to the detection of a cycle in an iterated mapping. Indeed, any 
mapping that is iterated on a finite set will eventually repeat, i.e., it will enter 
a cycle. If the mapping is a random mapping (rather than a permutation), the 
entry point to the cycle corresponds to a collision for the function (unless the 
starting point belonged to the cycle, but this event has a negligible probability). 
The detection of a cycle does not require storing all the values; for example, the 
technique of distinguished points can be used (one only stores special points, for 
example those points beginning with 30 zero bits). Cycle detection techniques 
were first applied to collision search by Quisquater [ng. The expected num- 
ber of function evaluations of his algorithm is about 2 • 2 ? ; the storage 

requirements are negligible. In nsni, van Oorschot and Wiener propose an effi- 
cient parallel variant of this algorithm: the speed-up is linear with the number 
of processors. They estimate that with a 10 million US$ machine, collisions for 
MD5 (with n = 128) can be found in 21 days (in 1994). In order to make a 
collision search infeasible, n should be at least 160 bits. This explains the second 
condition in Definition OofaCRHF. 

For digital signatures, hash functions need to be collision resistant since oth- 
erwise one can sign one message and later claim to have signed a different mes- 
sage, or be held accountable for a different message. There is no way to prevent 
a sender from performing this attack, although the occurrence of two messages 
that hash to the same value might make him suspect (in practice it might be 
very difficult to prove to a third party the denial). Outsiders can perform the 
same attack if they can convince the signer to sign a message of their choice. The 
sender can protect himself through randomizing the message just prior to signing 
(or by randomizing the hash function as is done for a UOWHF, cf. Sect. 1^ . 



6.2 Attacks Dependent on the Chaining 

This class of attacks depends on some high level properties of the compression 
function /. 

Meet-in-the-Middle Attack. This attack is a variation on the birthday at- 
tack, but instead of comparing the hash result, one compares intermediate chain- 
ing variables. The attack enables an opponent to construct a (2nd) preimage, 
which is not possible for a simple birthday attack. The opponent generates r\ 
variations on the first part of a bogus message and T 2 variations on the last 
part. Starting from the initial value and going backwards from the hash re- 
sult, the probability for a matching intermediate variable is again given by 



Cryptographic Primitives for Information Authentication — State of the Art 



81 



1 — exp(— n • The only restriction that applies to the meeting point 

is that it cannot be the first or last value of the chaining variable. The cycle 
finding algorithm has been extended by Quisquater to perform a meet-in-the- 
middle attack with negligible storage [HI- The attack can be precluded by 
avoiding functions / that are invertible to the chaining variable Hi-i and to the 
message Xi (see also Theorem ^ in Sect. 15.111 . 

Further extensions of this attack have been proposed by Coppersmith m and 
Girault et al. m to break p-fold iterated schemes, i.e., weak schemes with more 
than one ‘pass’ over the message as proposed by Davies M- Other extensions 
take into account additional constraints on the message. 

Correcting Block Attack. This attack consists of substituting all blocks of 
the message except for one or more blocks. This attack often applies to the last 
block and is then called a correcting last block attack, but it can also apply to 
the first block or to some blocks in the middle. For a (2nd) preimage attack, 
one chooses an arbitrary message X and finds one or more correcting blocks Y 
such that h{X\\Y) takes a certain value. For a collision attack, one starts with 
two arbitrary messages X and X' and appends one or more correcting blocks 
denoted with Y and Y' , such that the extended messages X\\Y and A'||y' 
have the same hash result. The hash functions based on modular arithmetic are 
especially sensitive to this attack. 

One can try to preclude a correcting block attack by adding redundancy to 
the message blocks, in such a way that it becomes computationally infeasible to 
find a correcting block with the necessary redundancy. The price paid for this 
solution is a degradation of the performance. 

Fixed Point Attack. The idea of this attack is to look for a iFi_i and Xi 
such that f(Xi,Hi-i) = Hi-\. If the chaining variable is equal to Hi-i, it is 
possible to insert an arbitrary number of blocks equal to Xi without modifying 
the hash result. Producing collisions or a second preimage with this attack is 
only possible if the chaining variable can be made equal to this is the 

case if IV can be chosen equal to a specific value, or if a large number of fixed 
points can be constructed (e.g., if one can find an Xi for a significant fraction of 
Hi-i’s). Of course this attack can be extended to fixed points that occur after 
more than one iteration. This attack can be made more difficult by appending 
a block count and by fixing IV (MD-strengthening, see Sect. t^. ill . 

Differential Attacks. Differential cryptanalysis studies the relation between 
input and output differences and is applicable to both block ciphers and hash 
functions HM. Interesting results were obtained by Biham and Shamir for 
FEAL, DES, N-hash, and Snefru. Differential attacks of hash functions based on 
block ciphers have been studied by Preneel and Rijmen !1.14ll4Sj . 

Analytical Weaknesses. Some MDCs allow manipulations as insertion, dele- 
tion, permutation, and substitutions of blocks. A large number of attacks have 
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been based on blocking the diffusion of the data input: this means that changes 
have no effect or can be canceled out easily in a next stage. This type of at- 
tacks has been successful for custom designed hash functions and for hash func- 
tions based on modular arithmetic. Among the most remarkable attacks in this 
class are the attacks developed by Dobbertin on the MDx-family ISTO . They 
combine conventional optimization techniques (simulated annealing, genetic al- 
gorithms) with conventional cryptanalytic techniques. Another property of the 
attacks is that differences are only controlled in certain points of the algorithms; 
this in contrast to differential cryptanalysis, where typically all intermediate 
differences are controlled to a certain extent. 

6.3 Attacks Dependent on Interaction with the Signature Scheme 

Even if the hash function is collision resistant, it might be possible to break the 
signature scheme. This attack is then the consequence of an interaction between 
both schemes. In the known examples of such an interaction both the hash func- 
tion and the signature scheme have some multiplicative structure (Coppersmith’s 
attack on X.509 Annex D E3). Damgard has proved that the security of a digi- 
tal signature scheme which is not existentially forgeable under a chosen message 
attack will not decrease if it is combined with a CRHF pnj (cf. Sect. It).4| l. 

A more subtle point is that problems can arise if the hash function and the 
digital signature scheme are not coupled. For example, given h(X), with h a 
strong CRHF, one could try to find a value X' such that h! {X') = h{X), where 
h' is a ‘weak’ hash function, and then claim that the signer has signed A' with 
h' instead of X with h. This problem can be solved by signing together with 
the hash result a unique hash identifier (for example, as defined in |k|), or by 
allowing only one hash function for a given signature scheme (DSA j66j and 
SHA-1 jti5]l. 

6.4 Attacks Dependent on the Underlying Block Cipher 

Certain weaknesses of a block cipher are not significant if the block cipher is used 
for encryption, but can have dramatic consequences if it is used in one of the 
modes for hashing. These weaknesses can be exploited to insert special messages 
or to carry out well chosen manipulations without changing the hash result. We 
will only discuss the weaknesses of DES ISH, because of its widespread use. 



Complementation Property. One of the first properties that was known of 
DES was the symmetry under complementation jSSj: V P, AT : C = DES(A, P) 
C = DES(AT,P). It can reduce an exhaustive key search by a factor 2 but 
it also allows to construct trivial collisions. 



Weak Keys. Another well known property of DES is the existence of four 
weak keys [1461 1 26j . For these keys, encryption equals decryption, or DES is 
an involution. These keys are also called palindromic keys. This means that 
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Ek{Ek{P)) = P, y P. There exist also 6 pairs of semi-weak keys, for which 
Ek 2 {Eki (P)) = P,y P. This property can be exploited in certain hash functions 
to construct fixed points after two iterations steps. 

Knudsen has identified other classes of weak keys m, namely weak hash 
keys and quasi weak keys. Quasi weak keys are keys for which there exists a 
simple relation between the corresponding encryption functions; DES has such 
keys which are not weak keys. 

Fixed Points. Fixed points of a block cipher are plaintexts that are mapped to 
themselves for a certain key. As a secure block cipher is a random permutation, 
it will probably have fixed points (for every key there is a probability of 1 — 
that there is at least a single fixed point). However, it should be hard to find 
these. For DES, it was pointed out that finding fixed points is easy for some keys 
H2S]: for every weak key Kp, there exist 2^^ values of P that can be easily found 
for which DES(ATp,P) = P. A similar property holds for the anti-palindromic 
keys: these are 4 semi- weak keys for which there exist 2^^ values of P that can 
be easily found for which DES(ATap, P) = P- 

Key Collisions. The collision search algorithm discussed in Sect. IP. ll ca.n also 
be used to construct key collisions for a block cipher. A key collision is a pair of 
keys Ki, K 2 such that Ek^ {P) = Ek 2 (P) for a plaintext P. For DES, there exist 
about (2^®)^/2®® = collisions for a given P. Finding one collision requires 
about 2’’/^ encryptions and very little storage, which is feasible for any block 
cipher with r < 128 . . . 160. However, a good design of the hash function can 
make the collisions useless. There is no easy way to guarantee this, and every 
scheme has to be verified for this attack. 

7 An Overview of MAC Algorithm Proposals 

In contrast with the variety of MDC proposals, very few MAC algorithms exist. 
The main reason is perhaps the fact that the existing standards are widely 
accepted. 

The general model for an iterated MAC algorithm is similar as the model for 
an MDC (cf. Sect. 15. 1 li . The main difference is that the compression function / 
and in some cases the initial value IV depend on the secret key K. Moreover, 
an output transformation is frequently used. Bellare et al. prove that iterating a 
finite size pseudo-random function provides a pseudo-random function that can 
take an input of arbitrary size HH. 

Three types of MAC algorithms are discussed: MAC algorithms based on 
block ciphers, MAC algorithms based on hash functions, and dedicated MAC 
algorithms. The performance in software of the first two type of MAC algorithms 
is discussed by Preneel et al. USE!. Note that if one is willing to use longer keys 
or update the key per message, one should consider the unconditionally secure 
schemes discussed in Sect.d the fastest of these schemes are significantly faster 
than the fastest MDCs and MACs. 
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7.1 MAC Algorithms Based on a Block Cipher 

The most popular method to compute a MAC is CBC-MAC, which uses the 
Cipher Block Chaining mode of a block cipher with IV = Hg = 0. The scheme 
appeared already in a 1977 document by Campbell E3; it has been included in 
several standards: ANSI X9.9 0, ANSI X9.19 0, FIPS 113 ES], ISO 8731 
and ISO/IEC 9797 gHl- 

H, = Ek{H,_i 0 X,) . 

Note that one can obtain the same output by using the Cipher FeedBack (CFB) 
mode, provided that an extra iteration is performed at the end. The standards 
differ because some of them mandate the use of DES as the block cipher, select 
one of the two modes, suggest other padding schemes, or leave open the number 
m of output bits. 

CBC-MAC is vulnerable to the so-called exor forgery attack that requires 
only one known text-MAC pair (cf. Sect. l8.2|l . This attack can be precluded by a 
strong output transformation (just chopping off some bits may not be enough). 

A good example of an output transformation is the encryption of the value 
Ht with a key derived from K (cf. ISO/IEC 9797 jSE! and For DES, an 

even better alternative is to replace the processing of the last block by a two-key 
triple encryption (with keys Ki = K and A2); this is commonly known as the 
ANSI retail MAC, since it first appeared in ANSI X9.19 0: 



g{Ht) = EkADkAHi)) ■ 



This mapping requires little overhead, and has the additional advantage that it 
precludes an exhaustive search against a 56-bit DES key; it also protects against 
theoretical shortcut attacks on DES (such as differential [in| and linear unsi 
attacks). 

Preneel and van Oorschot have shown that for the ANSI retail MAC, 2’'/^ 
known texts allow for a key recovery in only 3 • 2^ encryptions, compared to 
2^^ encryptions for exhaustive key search [1 42j (note that for DES r = 64 and 
k = 56). Another key recovery attack needs only a single known text, but re- 
quires about 2^ MAC verifications m- Moreover, it reduces the effective MAC 
size from min(r, 2fc) to min(r, /c). Apparently, the security of the ANSI retail 
MAC can be improved at no cost in performance by introducing a double DES 
encryption in the first and last iteration unsi: 

Hi = EkAEkAXi)) and g{Ht) = EkAHA ■ 

Here K '2 is derived from A 2 . 

A new mode to compute a MAC was suggested by Preneel j 1 ,441 1 4q) (called 
RIPEMAC): 

H, = EK{Xi®Hi_i)®X,. 

It has the advantage that the compression function is harder to invert, even for 
someone who knows the secret key. 
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All the CBC-MAC variants are vulnerable to the birthday forgery attack 
(cf. Sect. 18.21) . which requires a single chosen message and about known 
messages (if m = r); if m = r/2, an additional chosen messages are required. 
For DES with r = 64, 2^^ texts are required. Note that with a fast software DES 
implementation, this number of texts can be collected in a few hours. Bellare 
et al. provide a proof of security for CBC-MAC m i-e., they establish a lower 
bound to break the system under certain assumptions on the block cipher. It 
almost matches the upper bound provided by the birthday forgery attack. 

In 1995, Bellare et al. have proposed XOR-MAC H3. It is a randomized 
algorithm and its security can again be reduced to that of the block cipher. It 
has the advantage that it is parallelizable and that it is incremental, i.e., small 
modifications to the message (and to the MAC) can be made at very low cost. 
The use of random bits clearly helps to improve security, but it has a cost in 
practical implementations. Also, the performance is typically 25 to 50% slower 
than CBC-MAC. 

As has been pointed out earlier (cf. Sect. l4.4ll . if both authenticity and secrecy 
are protected using the same block cipher, the keys for both operations have to 
be different 

7.2 MAC Algorithms Based on a Hash Function 

The availability of fast dedicated hash functions (mainly of the MDx-family) 
has prompted several proposals for MAC algorithms based on these functions. 
The first proposals are the secret prefix and secret suffix methods which can 
be described as follows: h^iX) = h{K\\X), hxiX) = h{X\\K). However, both 
have certificational weaknesses: the first one allows for extension attacks, and 
the second one opens the possibility of off-line attacks IHD|. 

Another proposal is the secret envelope method, which can be described as 
hxix) = h{Ki\\x\\K 2 ) (for example Internet RFC 1828, considered for IPSEC). 
Bellare et al. provide a security proof for this construction based on the assump- 
tion that the compression function of the hash function is pseudo-random m 
While this is an interesting result, it should be pointed out that the compres- 
sion function of most hash functions has not been evaluated with respect to this 
property. Preneel and van Oorschot have developed a key recovery attack on the 
envelope method that requires about 2"/^ known texts fl41) (cf. Sect. tS.2ll . 

MDx-MAC, put forward by Preneel and van Oorschot in nm, extends the 
envelope method by also introducing secret key material into every iteration. 
This makes the pseudo-randomness assumption more plausible. Moreover, it 
precludes the key recovery attack by extending the keys to complete blocks. 

HMAC, proposed by Bellare et al. [II 0) . is currently the most popular con- 
struction in this class. It uses a nested construction (also with padded keys): 

hK{X) = h{K2\\h{K,\\X)) . 

HMAC will be used for providing message authentication in IPSEC (Internet 
Protocol security) and in the SSL 3.0 (Secure Sockets Layer). The security of 
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HMAC is guaranteed if the hash function is collision resistant for a secret value 
Hq, and if the compression function itself is a secure MAC for 1 block (with 
the secret key in the Hi input and the message in the Xi input). While these 
assumptions are weaker, we believe that the the latter one still requires further 
validation for existing hash functions. 

7.3 Custom Designed MAC Algorithms 

The Message Authentication Algorithm (MAA) was published in 1983 by Davies 
and Clayden in response to a request of the UK Bankers Automated Clearing 
Services (BACS) . In 1987 it became a part of the ISO 8731 banking stan- 

dard |HS|- The algorithm is software oriented and has a 32-bit result. Recently 
several undesirable properties of MAA have been exposed by Preneel et al. insi. 
They offer no immediate threat to current applications, but it would be advis- 
able to check for the known classes of weak keys m and to change the key 
frequently. Nevertheless, it is anticipated that MAA will be withdrawn from the 
revised version of ISO 8731. 

Several custom designed MAC algorithms in use have not been published, 
such as the S.W.I.F.T. authenticator, and the Swedish algorithm Data Seal. Pro- 
prietary MAC algorithms that can process only short messages include Telepass 1, 
the DECT standard authentication algorithm, the COMP 128 algorithm (which 
is used by certain GSM operators and was shown to be weak), and the Sky 
Videocrypt system of British Sky Broadcasting. 

8 Methods of Attack on MAC Algorithms 

This section summarizes the known methods of attack on MAC algorithms. 
Three types of attacks will be distinguished: 

1. attacks independent of the algorithm, 

2. attacks dependent on the chaining, 

3. high level attacks. 

A MAC requires a more complex taxonomy than an MDC: the proposed taxon- 
omy is equivalent to that of Goldwasser et al. tZBI for digital signature schemes. 
Depending on the information available to an attacker, the following types of 
attacks are distinguished: 

Known text attack: an attacker is able to examine some plaintexts and their 
corresponding MAC. 

Chosen text attack: an attacker is able to select a set of texts, and subse- 
quently he will obtain a list of MACs corresponding to these texts. 
Adaptive chosen text attack: this is the most general attack where an at- 
tacker will choose a text and immediately receive the corresponding MAC: 
the choice of a text can depend on the outcome of previous queries. In some 
settings it is also relevant for an attacker to ask for a verification whether a 
MAC corresponds to a specific text. 
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“Breaking” a MAC algorithm can have different meanings: 

Total break: this means that an attacker can determine the secret key K. 
Universal forgery: an attacker can find an algorithm that is functionally equiv- 
alent to the MAC evaluation algorithm. 

Selective forgery: an attacker can determine the correct MAC for a particular 
text chosen a priori by him. 

Existential forgery: an attacker can determine the MAC for at least one text. 
As he has no control over this text, it may be random or nonsensical. 

The second requirement in Definition 0can now be restated as follows: it should 
be “hard” to perform an existential forgery with an adaptive chosen text attack. 
Note that obtaining a MAC for a text from the owner of the secret key is not 
considered as a forgery. In practice, an adaptive chosen text may not always 
be feasible; moreover, forgeries typically need to have specific redundancy to 
be of any practical use. However, it is in general better to be conservative and 
to require that MAC algorithms (and digital signature schemes) resist against 
the strongest attacks possible; the only restrictions one should consider are the 
number of texts and the computational capabilities. 

For the attacks above, one requires that the forgery is verifiable, which means 
that the attacker knows that the forged MAC is correct with probability close 
to 1. 



8.1 Attacks Independent of the Algorithm 

This class of attacks depends only on the size m in bits of the MAC (it will be 
assumed that an output transformation g is used) and on the size k in bits of the 
secret key; it is independent of the specific details of the algorithm. It is assumed 
that the MAC algorithm approximates a random function: if this is not the case 
this class of attacks will be even more successful. 



Random Attack. A straightforward attack on a MAC algorithm consists of 
choosing an arbitrary new message, and subsequently guessing the MAC. This 
can be done in two ways: either one guesses the MAC directly, with a success 
probability of 2“™, or one guesses the key, and then computes the MAC, with 
success probability 2“^. This is a non- verifiable attack: an attacker does not know 
a priori whether his guess was correct. The feasibility of the attack depends 
on the number of trials that can be performed and on the expected value of 
successful attack; both are strongly application dependent. If the number of 
trials can be limited, or if the expected value is limited, a value of to = 32 is 
sufficient. However, for most applications it is recommended that the size of the 
MAC is at least 64 bits. 



Exhaustive Key Search. This attack requires approximately k/m known text- 
MAC pairs for a given key; one attempts to determine the key by trying one- 
by-one all the keys. The expected number of trials is equal 2^“^. In contrast 
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to a random attack, this attack is carried out off-line and it yields a complete 
break of the MAC. Contrary to what is believed, the size k of the key does not 
only depend depends on the time span during which the MAC algorithm has 
to remain secure. One can argue that it should also depend on the time during 
which the MAC application (with the same key size) is deployed. This is based 
on the fact that just a single success during the lifetime of the system might 
be sufficient for an important fraud. Therefore, at present, 56 bits seems to be 
marginal; 75. . . 80 bits is recommended as a reasonable value that provides some 
future protection (see also Sect. lO) . 

Birthday Attack. A birthday attack on a MAC algorithm might be possible, 
provided the opponent obtains a sufficient number of text-MAC pairs with a 
known or chosen text attack. In a typical application, this does not lead to a 
vulnerability. However, in certain special setting such as multi-destination secure 
electronic mail inni, a MAC algorithm should be second preimage resistant or 
even collision resistant for someone who knows the secret key. The MAC becomes 
then equivalent to an MDC. 

8.2 Attacks Dependent on the Chaining 

This class of attacks depends on some high level properties of the compression 
function /. They were published by Preneel and van Oorschot PUIHTI ; some 
related results by Bellare et al. can be found in mini. 



Exor Forgery. This type of forgery only works if the value of Hi is computed 
as a function of i7i_i © (as in CBC-MAC), and if no output transformation is 
present. This attack has been observed independently by several researchers. The 
easiest variant requires only a single known text. Assume that the input X and 
its padded version X consist of a single block. Assume that one knows hK{X); 
it follows immediately that hK{X\\{X © hxiX))) = hK{X). This implies that 
one can construct a new message with the same MAC value, which is a forgery. 
Note that this attack applies even if a MAC algorithm key is used only once. 
A second variant requires two known texts. If one knows hxiX) and hx^X')^ a 
similar calculation shows that hK{X\\{X^(B hxiX))) = hxiX'). A third variant 
uses three known texts. If one knows hx{X), hK{X\\Y), and hxiX'), one knows 
that hxiX'WY') = hx{X\\Y) HY' = Y (B hxiX) © hxiX') (if X and Y fall on 
block boundaries). This also allows for a forgery, as an adversary can forge the 
MAC on A'||y' given knowledge of the MACs for two known data strings and 
one chosen data string. Note that the above forgeries are on data strings of a 
specific form, which may not be a concern in all applications. 

Some further thought shows that this attack cannot be precluded by append- 
ing the length. A strong output transformation does help. However, Knudsen has 
shown that if the output transformation consists of retaining the m < r leftmost 
bits, a variant of the exor forgery attack applies; it requires chosen texts 
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Internal Collision Based Forgery. This section describes a generic forgery 
attack that applies against all iterated MAC algorithms (this includes all algo- 
rithms described in Sect. 0. The observation behind this attack is that if one 
can find a collision for the chaining variables, this can be used to construct a 
MAC forgery based on a single chosen text. 

Let (X,X') be a pair of message inputs with h{X) = g{Ht) and h{X') = 
g{H[). A chaining variable collision is said to occur when for some i < t, Hi = 
i.e., the intermediate chaining values coincide. An internal collision is said to 
occur when a chaining variable collision results in the situation where Ht = H[. 
In the following it will be assumed that g is deterministic: an internal collision 
yields a MAC collision. If Ht yf H't but g{Ht) = g{H't), then an external collision 
is said to have occurred. 

Lemma 1. An internal collision for an iterated MAC algorithm can be used to 
obtain a verifiable MAC forgery with a chosen text attack requiring only one 
requested MAC. 

Proof. For an internal collision {X, X'), note that h{X || Y) = h{X' || Y). for any 
single block Y . Thus requesting a MAC for the single chosen text X || Y , permits 
forgery - the MAC for X' || Y is the same. ■ 

Note that the attack can be precluded by making the output transformation g 
different for each MAC calculation, e.g., by including a sequence number or a 
sufficiently large random number in the calculation of g. 

The following theorem indicates how one can identify an internal collision for 
the attack of Lemma QJ 

Theorem 3 (Preneel-van Oorschot {140] ) . Let h be an iterated MAC algo- 
rithm with n-bit chaining variable and m-bit result. An internal collision for h 
can be found using u known text-MAC pairs and v chosen texts. The expected 
values for u and v are as follows: u = \/2 • 2"/^ and v = 0 if the output trans- 
formation g is a permutation; otherwise, v is approximately 



2 





The two most important cases in practice are n = m and n = 2m. In the 
first case. Theorem ^indicates that only 4 chosen texts are required; if n = 2m, 
about 2™+^ chosen texts are required. Further optimizations of this attack are 
possible if the set of text-MAC pairs has a common sequence of s trailing blocks. 
It should also be noted that the attack cannot be precluded by prepending the 
length of the input before the MAC calculation or by fixing the length of the 
input. The attack can be precluded by making the output transformation non- 
deterministic: this implies that chaining variable collisions will only lead with 
negligible probability to internal collisions. 



Internal Collision Based Key Recovery. For some compression functions 
/, one can extend the internal collision attack to a key recovery attack nm. 
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The idea is to identify one or more internal collisions; for example, if / is not 
a permutation for fixed Hi, an internal collision after the first message block 
gives the equation fK{Xi,Ho) = fK{X[,Ho), in which K and possibly Hq are 
unknown (it is assumed that the Hq = IV is key dependent). For some com- 
pression functions /, one can obtain information on the secret key based on such 
relations. Examples are the envelope method with two different keys ISect. 17?^ . 
MAA, and COMP128 (Sect. 17.811 . A related more subtle attack on RFC 1828 
recovers the secret key in the output transformation (Sect. 17.21 . 

8.3 High Level Attacks 

Even if the above attacks would not be feasible, special care has to be taken 
to avoid replay of messages and construction of valid messages by cutting and 
splicing others. Also the timeliness and the order of messages can be important. 
Attacks on this ‘higher’ level can be precluded by adding time stamps, serial 
numbers, or random challenges and through the use of sound cryptographic 
protocols. In the case of stored information, a restore can be avoided through 
the use of version numbers and the order of the blocks can be protected through 
adding the memory address to the information before the computation of the 
MAC. 

9 Digital Signature Schemes 

This section discusses some practical constructions for digital signatures. The 
most popular constructions are based on public-key techniques, but one can 
also construct digital signatures based on physical assumptions and based on 
conventional one-way functions. 



9.1 Based on Physical Assumptions 

A device like a smart card is called tamper resistant if one believes that it is 
difficult to access the secret key stored in it. One can use a smart card with a 
conventional cryptographic algorithm to build a signature scheme as follows: the 
‘signer’ has a smart card that can only encipher with a secret key K, and each 
‘verifier’ has a smart card that can only decipher with a secret key K . Forging 
a signature is hard if one believes that the devices are tamper resistant. The 
disadvantage of this approach is that the secret key K has to be installed and 
stored securely within the smart card of both signer and verifier(s). This should 
be contrasted with the schemes of Sect. 19.81 where only the secret key of the 
signer is protected in a smart card. 

9.2 Based on a Conventional One-Way Ftinction 

The first digital signature scheme based on a conventional one-way function 
(denoted with g) is the Difhe-Lamport one time signature ISD). In order to sign 
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a single bit message, the sender randomly selects a pair xi,X 2 € Dom(g) and 
computes j/i = g(xi) and j /2 = g{x 2 )- Next he puts in an authenticated 

public file. If he wants to sign the message, he reveals xi if the message bit equals 
0 and X 2 if the message bit equals 1. Subsequently the receiver can verify that 
Ui = g{xi). A second well known construction is the Rabin scheme |146| : the 
‘cut and choose’ technique proves to be a very powerful building block for other 
cryptographic protocols. 

The main disadvantage of these schemes are the size of keys and signatures 
and the fact that they can only be used for a fixed number of signatures (often 
only once). The optimizations by Merkle mu yield a scheme that is almost 
practical; Bleichenbacher and Maurer provide a generalization of these methods 
m- These basic schemes have served as a starting point for complexity theoretic 
constructions. 

9.3 Based on Public-Key Techniques 

An elegant solution to construct digital signatures was proposed by Difhe and 
Heilman in their seminal 1976 paper m in which they introduced the concept of 
trapdoor one-way functions. These functions are easy to compute in one direction 
and difficult to compute in the other direction, except for someone who knows 
the ‘trapdoor’ information. Information can then be digitally signed if the sender 
transforms the information with his secret key (the trapdoor information). The 
receiver can then verify the digital signature by applying the transformation in 
the ‘easy direction’ using the public key. The signature is unique to the sender 
because she is the only one who possesses the secret information. 

Trapdoor one-way functions can also be used for public-key encryption sys- 
tems, where the receiver can make his key public through an integrity protected 
channel. The encryption operation is then the transformation with the pub- 
lic key, and the decryption the inverse transformation (using the secret key or 
trapdoor). Note that in general the signing operation and the verification op- 
eration of a signature scheme are not equivalent to decryption and encryption 
respectively; this widespread misunderstanding has been created because this 
equivalence holds for RSA, which is discussed in the next paragraph. 

The first ‘secure’ trapdoor one-way permutation was proposed by Rivest, 
Shamir, and Adleman in 1977 [IS3|. The RSA public-key cryptosystem is based 
on modular exponentiation and its security relies on the difficulty of extracting 
modular roots modulo an integer that is the product of two large primes (this 
problem is related to factoring such integers). It is widely used and has become 
a “de facto” standard. A variant of RSA that is provably equivalent to factoring 
was proposed by Rabin P2|; it is based on modular squaring. The RSA and the 
Rabin scheme are the only public-key signature schemes that have a determin- 
istic signing procedure, i.e., the signing process does not need any random bits. 
Other efficient variants have been proposed based on the fact that even finding 
a good approximation for a modular square root is hard if the factorization of 
the modulus is not known. An example in this class is ESIGN [S3; this scheme 
is based on a modulus of the form n = p^q. 
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A second class of schemes is based on the discrete logarithm problem. The 
first scheme in this class was suggested by ElGamal in 1984 m Bleichenbacher 
points out some vulnerabilities of this scheme in [20] . An optimized variant was 
put forward by Agnew et al. j2). The Digital Signature Algorithm standardized 
by NIST [SEI also belongs to this class. It is based on the difficulty of the discrete 
logarithm in GF{p), where p is a large prime number (512 to 1024 bits) such 
that p — 1 has a 160-bit prime divisor q. The scheme exploits this structure to 
optimize storage and computation as suggested by Schnorr uni for a different 
scheme. The advantage of schemes based on the discrete logarithm is that they 
can be implemented in any group for which the discrete logarithm is believed 
to be hard. Recently some promising results have been achieved with schemes 
based on elliptic curves over finite fields (e.g., mm)- 

A third class of schemes is derived from zero-knowledge identification pro- 
tocols; the schemes can again be divided into two classes according to the un- 
derlying assumption. The variants based on factoring are Guillou-Quisquater 
PS] and Ohta-Okamoto H3U, and a variant with exponent 2 is the Feige-Fiat- 
Shamir scheme jODj . The variants based on the discrete logarithm problem are 
the schemes by Schnorr unsi and Okamoto [l.dUj . 

The schemes that have been mentioned in this section are all reasonably 
efficient, but they do not have the same level of provable security, i.e., the relation 
with the underlying hard problem might be different. What is important is how 
tight the relation is between forging a signature and breaking the underlying 
hard problem (for example extracting random modular roots for RSA). The 
schemes for which an even stronger reduction is possible (e.g., ISEHl) or the 
schemes based on more general assumptions (e.g., jl28ll56| 'l are however less 
practical. The closest to practical is the construction by Dwork and Naor m, 
which requires between two and six RSA computations and some extra public 
storage; signatures are also six times longer than the modulus. 

9.4 Combining a Hash Function and a Signature Scheme 

The main idea to speed up all digital signature schemes is to compress the 
information to be signed with an MDG to a string of fixed length (sometimes 
called “imprint”) and to sign this string. In order to verify the signature, the 
hash result is recalculated and is input to the computations of the verification 
procedure. For digital signatures schemes with message recovery, such as RSA, 
the imprint is recovered during the verification procedure and compared to the 
hash result of the received message (e.g., ISO/IFG 97976-1 |HZ])- There also 
exists a mixed mode, for which in addition to the imprint, part of the message 
is recovered (ISO/IFG 97976-2 

The advantages of combining a digital signature scheme with a hash function 
are the following: 

1. The size of the signature can be reduced from the size of the information to 
one block length, independent of the length of the signed information; for 
ISO/IFG 97976-2, the overhead of an RSA signature is reduced to approxi- 
mately 23 bytes. 
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2. The sign and verify function of most known signature schemes are several 
orders of magnitude slower in hardware and software than MDCs. 

3. If information is signed that is longer than one block, it is easy to manipulate 
these individual blocks. The simplest example is a reordering of blocks. 

4. The algebraic structure of the message space can be destroyed. In the case 
of RSA [SB| and discrete logarithm based signatures, the message space has 
a multiplicative structure, i.e., the signature of the product of two messages 
equals the product of their signatures. Examples of how this algebraic struc- 
ture can be exploited in a protocol are described by Gordon iza and Moore 

5. The reblocking problem can be avoided. This problem occurs when both 
privacy and authentication of a short message are protected (for example, 
using RSA), and the result of the signature process is larger than the modulus 
used for encryption. 

6. The signature protocol will not be useful for an opponent trying to obtain 
the plaintext corresponding to encrypted messages. This can only happen if 
one uses the same public-key cryptosystem and keys for privacy protection 
and authentication, which is not good practice anyway. 

For the zero-knowledge based signature schemes, the hash function is an 
integral part of the signing and verification operations, as it links together the 
information to be signed and some unpredictable and signature dependent infor- 
mation. However, this does not imply that it is sufficient that the hash function 
is a OWHF, as one always has to take into consideration a cheating signer. More- 
over, a somewhat stronger ‘randomization’ property is required in addition to 
collision resistance. Note that the requirements are different in the case of entity 
authentication; Girault and Stern have pointed out that resistance to multiple 
collisions (together with some ‘randomization’ properties) is sufficient m- 
In some cases there can be an unfortunate interaction between the digital 
signature scheme and the hash function (cf. Sect. Iti..3li . To avoid this problem, 
one can impose additional conditions on the hash function (e.g., it should be non- 
homomorphic, correlation free inn],...). An alternative approach, which seems 
preferable to us, is to solve the problems with the signature scheme: an example 
is the redundancy scheme for RSA (and its extension to even exponents) which 
was standardized in EZj: it destroys the homomorphic property as explained by 
Guillou et al. IHD]. However, this is not sufficient to reduce the security of the 
signature scheme to that of extracting random modular roots. This has been 
achieved by PSS or provably secure signing as proposed by Bellare and Rogaway 
m; they prove the security of PSS in the random oracle model; this means that 
the hash function is expected to behave in an ‘ideal’ way. 



9.5 Selecting a Signature Scheme 

When selecting a particular signature scheme, one has to consider the following 
aspects: 
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efficiency in terms of storage and computation: number of operations for 
signing and verifying, size of secret and public key, size of the signature, and 
the possibility of preprocessing. 

random: randomized signatures will probably leak less information about the 
secret key, but on the other hand the signer needs to produce random bits 
in a secure way (if the random input is revealed, not only the signature but 
the secret key might be compromised). 

security: is the scheme well established, and how strong is the reduction to the 
underlying hard problem? 

hash function: the requirements to be imposed on the hash function. 

patents and standards: these non-technical aspects will also influence the 
choice of a particular scheme. 



9.6 Some Practical Considerations 

After a slow start, digital signature schemes are now getting more widely ac- 
cepted. An important problem is a user who looses his secret key, or who claims 
he has lost his secret key. In both cases he will try to revoke his digital sig- 
natures. Any practical signature scheme has to implement procedures for the 
revocation of keys. In order to minimize this risk, one can store the secret key in 
a tamper resistant device (e.g., a smart card), such that even the owner does not 
know it, and one can maintain black lists for users with a bad history. This will 
make fraudulent revocations very difficult. A second problem is that after some 
time, the signature scheme might be broken (due to advances in cryptanalysis); 
in order to avoid that the legal validity of the signature (more precisely, of the 
contract created with the signature) is lost, one needs to register a digital sig- 
nature, or to use arbitrated signature schemes, where a third party is involved 
in the signing process. Recently significant progress have been made towards 
legal acceptance of digital signatures under several jurisdictions (for example, 
Germany, Utah, and the European Directive), but progress is still rather slow. 
Legal support of digital signatures is certainly necessary to get a wide accep- 
tance and will be a significant step forward to the wide deployment of electronic 
commerce. 

10 Conclusions 

For protecting information authentication, several cryptographic techniques are 
available: MAGs, MDGs, and digital signatures. 

For MAGs, efficient standards exist that are widely accepted. The security 
level of the widely used GBG-MAG is lower than anticipated, but as soon as 128- 
bit block ciphers will be available, this problem will have been resolved. A recent 
trend is to construct MAG algorithms based on MDGs. For concrete candidates, 
some additional research is required to assess the security of these proposals. For 
applications where performance and communication overhead are crucial (such 
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as authentication of packets at the IP level) MAC algorithms are still preferred 
over digital signatures. 

For authentication between mutually distrusting parties, as is required in 
electronic commerce, digital signatures offer an essential solution. In the coming 
years, one can expect a wide deployment of the infrastructure to support this 
technology, the so-called PKIs (public key infrastructures). Further theoretical 
developments together with legal support will make digital signatures widely 
accepted. 

The most important application of MDCs is in digital signatures, but they 
have been used as a flexible tool in different cryptographic constructions. While a 
few MDCs seems to be widely trusted, further research is required to increase our 
understanding of design principles and to provide more efficient constructions. 
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Abstract. This paper examines proposals for three cryptographic prim- 
itives: block ciphers, stream ciphers, and hash functions. It provides an 
overview of the design principles of a large number of recent proposals, 
which includes the global structure, the number of rounds, the way of in- 
troducing non-linearity and diffusion, and the key schedule. The software 
performance of about twenty primitives is compared based on highly op- 
timized implementations for the Pentium. The goal of the paper is to 
provided a technical perspective on the wide variety of primitives that 
exist today. 



1 Introduction 

An increasing number of applications uses software implementations of crypto- 
graphic algorithms in order to provide an acceptable security level at a low cost. 
An important constraint is that the performance of the application should be 
influenced as little as possible by the introduction of cryptography. The design of 
secure cryptographic primitives which achieve very high software performance 
is a challenging problem for the cryptologic research community. This paper 
intends to report on the state of the art on this problem. 

The best which can be achieved currently is to design fast primitives with 
some provable properties, but the general paradigm is still a ‘trial-and-error’ 
procedure, which consists of the publication of candidate algorithms and an 
evaluation by cryptanalysts. In this process, the cryptographic community gath- 
ers knowledge on how to design cryptographic algorithms. Note that primitives 
exist which are provably secure based on some reasonable assumptions (such as 
the difficulty of factoring the product of two large primes), but these are several 
order of magnitude slower than the fastest algorithms currently in use. 

This paper intends to summarize the state of the art by comparing the dif- 
ferent approaches and design choices and their performance in software. It is not 
our intention to give an in-depth security analysis of any primitive or to assess 

* F.W.O. postdoctoral researcher, sponsored by the Fund for Scientific Research - 
Flanders (Belgium). 

** F.W.O. research assistant, sponsored by the Fund for Scientific Research - Flanders 
(Belgium). 



B. Preneel, V. Rijmen (Eds.): COSIC’97 Course, LNCS 1528, pp. 105-^201 1998. 
(c) Springer- Verlag Berlin Heidelberg 1998 



106 



Bart Preneel, Vincent Rijmen, and Antoon Bosselaers 



their suitability for a certain application. The main goal is to extract some gen- 
eral principles, such that potential users, cryptanalysts, and designers have an 
idea of the diverse approaches of the present day cryptographic primitives. 

In this paper three types of cryptographic primitives are considered: additive 
stream ciphers, hash functions, and block ciphers. First these primitives will be 
introduced briefly. Next, brute force attacks on them will be presented. In m 
the different design principles are described. discusses the evaluation of their 
security and ^compares the software performance. The conclusions are given 
in 33 The status of selected primitives is listed in Appendix A. 

2 Cryptographic Primitives 

This paper focuses on the three most common cryptographic primitives: addi- 
tive stream ciphers, cryptographic hash functions, and block ciphers. It will be 
assumed that the reader is familiar with the basic requirements for these prim- 
itives, as well as with the ways how these primitives can be used to provide 
security services such as confidentiality and authentication. 

2.1 Additive Stream Ciphers 

Additive stream ciphers stretch a short key and an initial value to a key-stream 
sequence. If data confidentiality is required, the sender will add this key-stream 
sequence to the data, simulating the operation of a one-time pad (but without 
the perfect secrecy) . The recipient can recover the data by subtracting the same 
key-stream sequence. Additive stream ciphers are also known as pseudo-random 
string generators. 

The stream ciphers that are discussed here are ‘alleged RC4,’ SEAL, and 
WAKE. The cryptographic literature contains a large number of papers on other 
constructions derived from linear feedback shift registers (see for example IZBI). 
Important examples include nonlinear filter functions and clock controlled shift 
registers. They are usually defined at bit level, which makes them more suited 
for hardware than for software. Although it is certainly possible to adopt these 
constructions to software environments, they will not be considered in this paper. 

2.2 Cryptographic Hash Fhnctions 

Cryptographic hash functions compress strings of arbitrary lengths to strings of 
fixed lengths (typically 64, 128 or 160 bits). In addition, they satisfy the following 
properties P1SS|: 

— preimage resistance: it should be hard to find a preimage for a given hash 
result; 

— 2nd preimage resistance: it should be hard to find a 2nd preimage for a given 
input; 

— collision resistance: it should be hard to find two different inputs with the 
same hash result. 
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While these properties are simple, experience has learned us that achieving them 
is quite hard. 

Hash functions are used frequently in combination with digital signature 
schemes; other applications include data integrity, commitment to a string, and 
the protection of passphrases. 

The hash functions discussed in this paper are MD4, MD5, SHA-1, RIPEMD- 
160, MD2, Snefru, N-hash, Subhash, and Tiger. The first four belong to the 
so-called ‘MD4- family.’ 



2.3 Block Ciphers 

Block ciphers transform a relatively short string (typically 64 or 128 bits) to a 
string of the same length under control of a secret key. 

The advantage of block ciphers is that they form a flexible tool that can 
be used for encryption: the properties of the encryption depend on the mode 
(ECB, CBC, CEB or OFB-mode) in which the block cipher is used |35I41 ) : for 
example, the OFB-mode provides an additive stream cipher. Block ciphers can 
also be used to construct other primitives, such as hash functions, and MAGs 
(see H2.4I . 

The popularity of block ciphers in cryptography is closely related to the 
popularity of DES, the Data Encryption Standard The publication of DES 
as a Federal Information Processing standard in 1977 has influenced conventional 
cryptography in a major way: DES became widely used to provide cryptographic 
protection. For some time, the existence of DES (and triple-DES) has made it 
very difficult for alternative block ciphers to gain acceptance. One can anticipate 
that this popularity will be continued, as NIST is preparing for a successor of 
the DES, the AES (Advanced Encryption Standard). 

This paper compares the following block ciphers: DES (and 3-DES), FEAL, 
IDEA, Blowfish, Khufu, SAFER (and variants), LOKI91, CAST, RC5, SHARK, 
SQUARE, MISTYl and MISTY2, and 3- WAY. 

2.4 Other Primitives 

The above list of primitives is certainly not complete: Message Authentication 
Codes (MACs) are conventional cryptographic algorithms which allow a receiver 
to establish the source and the integrity of data received . Most MAC con- 
structions in use at present are derived from either block ciphers or hash func- 
tions. Recently new MACs have been developed in a setting where the secret key 
is used only once, as for the one-time pad (e.g., MMH by Halevi and Krawczyk 
m)- However, these solutions can be made very practical by deriving the actual 
key from an external key using an additive stream. These new MAC construc- 
tions have combinatorial rather than cryptographic properties, which apparently 
makes it much easier to achieve very high speeds. 

Self-synchronizing stream ciphers are important for applications where syn- 
chronization is critical, but few dedicated proposals are known. The CEB-mode 
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of a block cipher is a popular way to implement a self-synchronizing stream 
cipher. 

Asymmetric or public-key cryptography plays an important role in many 
applications; however, to date no asymmetric algorithm has been found which 
achieves a speed comparable to the primitives discussed above. 

Also note that several reductions between primitives have been developed: 
for example, one can construct a block cipher from an additive stream cipher 
and a hash function. Two examples of this construction are LION and BEAR j0|, 
both based on a combination of an additive stream cipher and a hash function 
(SEAL and SHA-1 are used as examples). Reductions can also be used to improve 
the strength of a given primitive. For example, triple-DES (with two or three 
keys) and DES-X are DES variants which increase the effective key size. In 
addition, they can be proved to be at least as secure (or even more secure) than 
DES itself. While this is certainly important for practical applications (reuse of 
existing implementations and transfer of trust), it should be pointed out that 
with the same computational effort, a more secure primitive could be built from 
scratch. The focus of this paper is mainly on the construction of basic primitives. 



3 Brute Force Attacks 

This section reviews brute force attacks on the three primitives. 



3.1 Additive Stream Ciphers 

The most important brute force attack is an exhaustive key search. Such an 
attack requires only a small amount of known plaintext and can be extended to 
a ‘ciphertext only’ setting. For an ideal additive stream cipher with A:-bit key, 
searching the key space requires 2^ encryptions. For long term security (10 years 
or more), k should be at least 75 to 90 bits P|; 128 bits provide an ample margin. 

A potential problem of additive stream ciphers is that the key-stream will 
eventually repeat. If the internal state consists of m bits, this will happen after 
about 2"*/^ bits if the next state function is a random function. If the next state 
function is a permutation, one expects repetitions after 2"*“^ bits. A sufficiently 
large value of m can preclude this attack. 

In addition, one should be cautious for weaknesses introduced by the resyn- 
chronization procedure (see e.g., |^). 



3.2 Hash Functions 

For a hash function with an n-bit result, brute force attacks to find a preimage 
or a 2nd preimage require about 2” hash operations. It should however be noted 
that if t targets can be attacked simultaneously, the success probability increases 
with a factor of t (or alternatively, the work factor is reduced with the same 
factor). This can be avoided by parameterizing the hash function. For (2nd) 
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preimage resistance, a value of n = 75 to 90 is sufficient for 10 years (for a 
parameterized hash function). 

Finding a collision with a square root attack (also known as birthday attack) 
requires about 2"/^ operations and very little memory Eins- Moreover, it can 
be parallelized efficiently. This implies that n should be at least 160 for long-term 
collision resistance. 



3.3 Block Ciphers 

A first general attack on a block cipher is an exhaustive key search; it requires 
a few known plaintexts, and can be extended to a ‘ciphertext only’ attack. As 
an example, the 56-bit key size of DES poses a serious problem for applications 
which require more than short term security: with dedicated hardware costing 
about 1 million US$, a DES key can be recovered in about an hour; the cost per 
key is less than 50 US$ m- Currently several efforts are underway to search for 
a DES key using idle cycles on the Internet; one expects that the elapsed search 
time will be less than 5 months. 

One can also construct a table which lists all the plaintext/ciphertext pairs 
of a block cipher for a given key. This attack can be precluded by choosing a 
large block length, or by changing the key frequently. If the block size n is 64 
bits or more, such an attack poses no problem. 

Other attacks on block ciphers are based on the way in which the block 
cipher is used. For example, if one fixed plaintext is encrypted using t different 
keys, exhaustive key search becomes faster with a factor of t. If an n-bit block 
cipher is used in CBC, CFB, or OFB mode, information on the plaintext starts 
to leak after 2”^^ encryptions m This shows that block lengths of 128 bits are 
desirable in the near future. It is therefore quite surprising that only two block 
ciphers (namely RC5 and SQUARE) allow for this block size (SHARK could be 
extended easily as well) . An alternative to a large block size is to change the key 
frequently, or to use more complex modes (for example, f21)l7,'H l. 

An important factor in the development of new block ciphers is the recent 
progress in cryptanalysis (such as differential and linear cryptanalysis |S|)- 
For DES, these shortcut attacks still require a huge number of chosen respec- 
tively known plaintexts, which renders them unrealistic. These new cryptanalytic 
techniques have brought new insights in the security of cryptographic primitives. 
Furthermore, these developments have stimulated research on building blocks 
such as S-boxes and diffusion layers. 

4 Design Principles for Cryptographic Algorithms 

Designing a slow and secure algorithm is easy for someone who understands 
the current designs and their strengths and weaknesses (see also (Q. For ex- 
ample, composition constructions exist which are at least as secure as each of 
the building blocks. If on the other hand the performance has to be pushed to 
the limits, a thorough analysis has to be combined with a good understanding 
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of the limitations of the processor or technology in which the system has to be 
implemented. While it is clear that the performance of primitives depends on the 
implementation details, even for a given environment (processor and memory in 
software, and power and area constraints in hardware), very little is known on 
which structures provide the best security (for a given number of instructions 
per encrypted or hashed byte) . Key issues are clearly the use of memory and the 
amount of parallelism. This section summarizes the different design aspects: 

— global structure and number of rounds; 

— non-linearity; 

— diffusion; 

— key schedule. 

Note that this selection of topics is tuned towards block ciphers; hash functions 
do not have a key schedule (but need to specify how to introduce the input bits 
into each iteration), and the design of additive stream ciphers follows usually a 
different approach (see § tt.ot . 

4.1 Global Structure and Number of Rounds 

Hash functions and block ciphers operate on relatively large inputs (64 . . . 256 
bits). These primitives are designed based on a principle proposed by Shannon 
nonlinear substitutions are alternated with mixing functions. The result of 
the combination is that “any significant statistics from the encryption algorithm 
must be of a highly involved and very sensitive type — the redundancy has been 
both diffused and confused by the mixing transformation. ” In the seventies Feis- 
tel m proposed to use a round transformation, consisting of small non-linear 
components and a transposition (or bit permutation) . The strength of a crypto- 
graphic primitive can be obtained by repeating this simple transformation. For 
a block cipher, the secret key has to be introduced in every round as well. 

If every input bit is treated in a similar way, one can speak of a uniform trans- 
formation; sometimes such transformations are called SPN networks (substitu- 
tion-permutation networks). An example of such a network is given in Figure Q 
A disadvantage of this approach is that the inverse function (which is required 
for decryption in case of a block cipher in ECB or CBC-mode) may be different 
from the function itself. This can be a problem for hardware and smart card 
applications. A clear advantage is the inherent parallelism. Examples of block 
ciphers in this class are SAFER, SHARK, SQUARE, and 3- WAY. Subhash is a 
hash function using this approach. 

A different approach consists of dividing the input into two halves, and ap- 
plying a non-linear function only to the right half. The result is added into the 
left half, and subsequently left and right half are swapped. Ciphers following this 
approach are called Feistel ciphers (see also Figure EJ. Since the nonlinear part 
requires most of the computation, two rounds of a Feistel cipher require about 
the same effort as a uniform transformation. The output of one nonlinear func- 
tion is input directly to the next one, which decreases the amount of parallelism 
but increases the propagation of local changes. Due to the special structure of 
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Fig. 1. One round of SHARK, a block cipher with the uniform transformation 
structure. The nonlinear layer is implemented with eight parallel S-boxes. 



the round function, the nonlinear function itself need not be invertible, and the 
round function is an involution. Since DES is a Feistel cipher, more cryptanalytic 
experience is available on Feistel ciphers than on any other general structure. 
Other Feistel ciphers are FEAL, Blowfish, Khufu, LOKI91, CAST, and MISTYl. 

The approach of a Feistel cipher can be further extended by dividing the 
input into more parts (ciphers constructed in this way have been called general 
unbalanced Feistel networks ISH). This may lead to a faster propagation of 
changes, but could reduce parallelism (depending on the nature of the nonlinear 
functions). This type of approach is used by the MD4-family, MD2, Tiger, and 
Snefru. 

Other variants and extensions of uniform transformations and Feistel ciphers 
have been proposed. RC5 is almost a Feistel cipher, since a part of the left half 
influences the transformation of the right half. MISTY2 is a Feistel variant which 
increases parallelism: by moving the nonlinear function to a different place, its 
input in the next round is already known before its output in the current round 
is calculated, so that calculations for two consecutive rounds can be carried out 
at the same time. IDEA is a also a variant: a function is computed of the sum 
of the two halves, and the result is added to the two halves (such that their sum 
remains a constant). 

The main conclusion which can be drawn from this section is that for the time 
being no conclusion can be drawn on which global structure is best. Different 
approaches have advantages and disadvantages, and it seems not very likely that 
clear winners will emerge in the near future. 

Number of rounds Most block ciphers and hash functions obtain their strength 
from repeating a number of identical rounds (one exception is CAST: some 
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members of this cipher family have different rounds) . In the key paper of Luby 
and Rackoff m it is shown that a 3-round Feistel network can provide a prov- 
able secure construction of a pseudo-random permutation from a pseudo-random 
function (4 rounds are required if both chosen plaintext and chosen ciphertext 
attacks are allowed). Further extensions of this research have shown that the 
proofs can be extended if some of the rounds contain functions with combinato- 
rial rather than cryptographic properties m- 




Kx 






Fig. 2. Two rounds of the DES, the most famous block cipher. It has the Feistel 
structure. E denotes the linear expansion of the 32 input bits to 48 input bits, 
0 denotes the bitwise exor with the round key, S is the nonlinear substitution 
and P is the bit permutation. 



While this provides some theoretical support for the Feistel structure, this 
work has been misinterpreted by others with regard to its impact on practical 
ciphers. For example, this research is orthogonal to the issue whether one should 
have many simple rounds or only three or four more complex rounds. The fact 
that most proofs seem to achieve their limit at three or four rounds is the conse- 
quence of the shortcomings of the model and the proof techniques, rather than 
a suggestion that ciphers with fewer but more complex rounds are better. An 
important shortcoming is that while being a pseudo-random permutation is a 
necessary condition for a good block cipher, it is not sufficient. Moreover, if the 
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round functions are instantiated by a smaller block cipher, other attack models 
have to be taken into account m- 

There is no doubt one has to check very carefully the resistance to linear 
and differential attacks. However, one should take into account that several ded- 
icated attacks have been developed which are only applicable to ciphers with a 
small number of rounds (< 8). The most general of these are meet-in-the-middle 
attacks HI]. Another trick used in these attacks is to peel off one or two rounds 
(by searching over part of the round keys), and attack the ‘weak’ structure that 
remains. Attacks on ciphers with few rounds include: 

— meet-in-the middle attacks exploiting the key schedule El; 

— key recovery attacks on 4 or 5 rounds of ladder-DES iS; 

— higher order differentials (up to 6-8 rounds); 

— interpolation attacks (for ciphers with S-boxes with a simple algebraic struc- 
ture) pTTij : 

— attacks on Feistel ciphers with non-surjective round functions (up to 8 rounds) 

— structure attacks, which exploit the structure of a uniform round transfor- 
mation 



4.2 Nonlinearity 

A nonlinear component is essential to every strong cryptographic primitive. The 
goal of the designer is to build a ‘large’ nonlinear primitive from smaller ones. 
The design approaches differ in the choice of the basic nonlinear component. 

A straightforward way to implement simple nonlinear functions are lookup 
tables or S-boxes. The DES uses eight different S-boxes with 6 input bits and 4 
output bits (denoted with 6^4); the total size of 256 bytes was clearly dictated 
by hardware constraints of the mid 1970’s. Byte level S-boxes (8 ^ 8) are very 
popular as they are suited for software implementations on 8-bit processors. 
Ciphers which use such S-boxes include SAFER, MD2, alleged RC4, SHARK 
and SQUARE. LOKI91 uses S-boxes of type 12 ^ 8. 

For modern processors with 32-bit or 64-bit words, S-boxes with more output 
bits can provide higher efficiency (although small S-boxes can be implemented 
efficiently by combining several S-boxes). An important concern is that the S- 
boxes should fit in the fast cache memory. Snefru was the first cipher to use 
8 — > 32 S-boxes; this example was followed by Blowfish, Khufu, CAST, and 
SQUARE. SHARK and Tiger use even larger lookups (8 ^ 64). For SHARK 
and SQUARE these are obtained by combining the byte-level S-boxes with the 
diffusion operation. 

For Blowfish, Khufu and alleged RC4, the S-boxes contain secret values, 
which makes attacks more difficult: typically, an attacker has to recover all the 
S-box entries, which is harder than finding the short round keys. In the case of 
alleged RC4, the value of the S-box is updated during every step. 

The value of S-boxes is often selected at random (e.g., MD2 and Snefru), 
or carefully selected to achieve certain properties (e.g., DES). In both cases 
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built-in trapdoors can be a problem. This has been demonstrated by two of the 
authors in m-- this paper shows how an undetectable trapdoor can be built into 
a block cipher. From the cryptanalytic results available, one can conclude that 
resistance against linear or differential cryptanalysis is not a property of S-boxes 
or of linear mappings, but rather of the combination of both. However, for a 
similar diffusion structure, increasing the size of the S-boxes will increase this 
resistance (e.g., LOKI91 versus DES). 

In the case of SAFER, MISTYl, MISTY2, SHARK, and SQUARE the S- 
boxes contain some mathematical structure (such as an exponentiation over a 
finite field). In MISTYl and MISTY2 the larger S-boxes have been built from 
smaller Feistel ciphers to allow for an efficient implementation. 

If the nonlinear operation does not come from table lookups, it is realized 
using the processor instructions available. FEAL uses addition and rotation; 
the MD4-family adds to this also simple bitwise Boolean functions; IDEA uses 
addition and multiplication. The innovative choice for RC5 was data dependent 
rotations (in addition to additions and exclusive ors). A special case is 3- WAY: 
it uses a very simple Boolean function, which can also be considered as a 3 ^ 3 
S-box. 



4.3 Diffusion 

In order to restrict the complexity of the implementation, nonlinear operations 
can only be applied to small parts of the block. Several techniques are used to 
spread local changes. 

Linear transformations are very well suited for this purpose. The simplest 
solution is a bit permutation (or transposition), as is used by DES, LOKI91, and 
Subhash, or a rotation, as in Khufu and Khafre. An alternative is to add the 
output of several S-boxes, as is done for Blowfish and CAST. More general linear 
transformations are the pseudo-Hadamard transform used in SAFER, and the 
diffusion operation based on MDS (Maximum Distance Separable) linear codes 
used in SHARK and SQUARE. 

Some cryptographic primitives have no separate diffusion operation, but com- 
bine linear and nonlinear operations in such a way that changes are spread 
quickly through the block. Examples of this approach are FEAL, IDEA, and the 
MD4-family. 

4.4 Key Schedule 

The key schedule is an important component of a block cipher; it computes 
the round keys from the external key. For many applications, the key schedule 
should not be too slow: some applications require very fast key schedules. Exam- 
ples are constructions for hash functions based on a block cipher, and banking 
applications which use a new session key per transaction. On the other hand, 
enumerating the key space should not be too easy in order to frustrate an ex- 
haustive key search. Large key dependent S-boxes (as found in Blowfish and 
Khufu) do not foster a quick key change. 
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One issue is the existence of weak keys, i.e., keys for which the block cipher is 
more vulnerable. Weak keys have been identified for DES, LOKI91, and IDEA. 
Ideally, such keys should not exist. If they form only a sparse subset of the key 
space, they pose no security problem if the block cipher is used for encryption; 
they can be a problem for other applications such as hash functions based on 
block ciphers. 

Recently related key attacks have been developed, in which an attacker ob- 
tains ciphertext corresponding to keys with a known or chosen relation (see 
for more details). The lesson learned from these attacks is that key sched- 
ules should not be too simple. 

Again many approaches can be distinguished, varying from a selection of 
bits (DES), over a rotation operation (SAFER, LOKI91, IDEA), to nonlinear 
operations (CAST). SQUARE uses a key scheduling based on linear codes to 
guarantee a large distance between round keys from different external keys. The 
importance of a good key scheduling is demonstrated with the case of SAFER. 
After the attack of L.R. Knudsen m on SAFER-K, the key scheduling has 
been improved by adding a parity byte to the round keys (this is actually a very 
simple linear code). The new SAFER is called SAFER-SK. 

Some block ciphers such as Blowfish, SHARK, and RC5 use the block ci- 
pher itself (with fixed round keys) to perform the key schedule. The hash func- 
tion SHA-1 uses a variant of a shortened cyclic code to diffuse the message 
input throughout the calculations (this operation plays the same role as the key 
schedule of a block cipher). Tiger also applies a diffusion transformation to the 
message input; it consists of Boolean operations, additions, and rotations. 



4.5 Stream Ciphers 

The above criteria are mostly related towards block cipher and hash functions. 
Below the most important design choices of three additive stream ciphers are 
discussed. The small number of proposals does not yet allow to identify general 
approaches. 

SEAL uses basic operations borrowed from the MD4-family, and is tuned 
to be fast on the 80486 processor. It derives a large part of its strength from a 
strong re-keying procedure for every ‘block’ which uses the hash function SHA-1. 
This re- keying is quite slow, which implies that the performance depends on the 
‘block’ size. 

Alleged RC4 is a very innovative design using a 256-byte table (containing 
an 8-bit permutation) which is updated during every iteration. Its description is 
very simple; the basic operations are some additions and table lookups on bytes. 
The key schedule converts a key of arbitrary size to a random 8-bit permutation. 

WAKE uses a series of additions, shifts, and exor operations with the entries 
of a key dependent table. A variant of WAKE, called WiderWAKE has been 
developed which can be up to 3.5 times faster by exploiting processor parallelism 
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5 Security Evaluation 

As explained in the introduction, the current approach to the design of crypto- 
graphic primitives is still largely based on a ‘trial-and-error’ procedure. 

The problems with this approach are that the evaluation phase is typically 
much more labour intensive than the design phase and provides less guarantees 
for success. Moreover, the targets chosen are not always the most important 
ones from a theoretical viewpoint: one will go after the primitive that attracts 
the most attention (because it is widely used, or because its designer is a well 
established cryptographer), or that requires least effort. It is safe to state that 
our knowledge on the design of algorithms has progressed significantly during 
the last decade, but on the other hand none of the designs currently in use has 
received what one could call a thorough scrutiny (more than one person-year). 
This should be compared to the 17 person-year design effort of DES; probably 
much more effort has been spent on the evaluation of DES. 

The lack of evaluation is sometimes compensated for by an ‘engineering fac- 
tor’ (over-design with a factor of two), which is acceptable for applications which 
can afford it, but poses problems for critical applications such as hard disk en- 
cryption. This is of course not an excuse to use unpublished algorithms which 
achieve a high performance at the cost of security (adding the same 32-bit key 
to all the data words is a widespread example of this) . On the other hand, it is 
quite clear that someone with a good understanding of present day cryptanalysis 
can design a secure but slow algorithm with a very limited effort: 

For a block cipher, it is sufficient to define a round function based on a 
nonlinear operation (avoid linear relations) and a simple mixing compo- 
nent (to spread local changes); add round keys in between the rounds 
(and at the beginning and end of the cipher), which are derived in a com- 
plex way from the key (e.g., by using the block cipher itself with fixed 
round keys). If the number of rounds is 32, or even better 64, breaking 
this slow block cipher will be very difficult. (Of course it is possible to 
follow this ‘recipe’ and to come up with a weak cipher, but this will 
require some cryptographic skills !) 

If a cipher is a variant or extension of an existing construction (such as DES 
with modified S-boxes and key schedule), a quick evaluation based on known 
cryptanalytic techniques can provide a good insight in the basic security. If these 
modifications have been made to avoid certain attacks, there exists however the 
possibility that improved versions of these attacks will still apply; this can lead 
to a loss of the intended improvement. The more innovative a cipher is, the 
more work needs to be done on the evaluation, since cryptanalysis requires the 
development of completely new techniques. 

Recently some progress has been made with respect to the existing paradigm 
by ciphers which were proven to be secure against differential and/or linear 
cryptanalysis. The first construction was the Nyberg-Knudsen scheme [61^ . fol- 
lowed by constructions by Nyberg [03, and MISTYl and MISTY2 by Matsui 
One should however keep in mind that ‘provable security’ is probably one 
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of the most misused terms in cryptography and that provable security against 
one or two important attacks does not imply that the cipher is secure: other 
attacks might exist, such as attacks based on truncated differentials (Knudsen, 
m)- This can be illustrated by a variant of the Nyberg-Knudsen scheme, which 
turns out the be very vulnerable to an interpolation attack m- On the other 
hand, provable security against certain attacks is certainly a first step in the 
right direction. 



6 Performance Evaluation 

Optimizing the performance of software and hardware is quite different. Fast 
hardware relies on parallelism and pipelining, while for software the access to 
memory is a key to high performance: the designer tries to minimize access 
to slow memory, and to stay as much “on chip” (registers and cache memory) 
as possible. However, parallelism becomes more important for software as well: 
recent evolutions in general purpose processors are clearly oriented towards more 
inherent parallelism, both on the hardware level (multiple execution units) and 
the software level (SIMD instructions). Two basic multiple-issue architectures 
can be distinguished: superscalar and very long instruction word (VLIW). 

— A superscalar processor has dynamic issue capability: a varying number of 
instructions is issued every clock cycle. The hardware dynamically decides 
which instructions are simultaneously issued and to which execution units, 
based on issue criteria and possible data dependencies. 

— A VLIW processor has fixed issue capability: every clock cycle a fixed num- 
ber of instructions is issued, formatted as one long instruction (hence the 
name). The software (i.e., the compiler) is completely responsible for creat- 
ing a package of instructions that can be issued simultaneously. No decisions 
about multiple issue are dynamically taken by the hardware. 

An example of the speedup that can be achieved by this kind of parallel process- 
ing is given by WiderWAKE, which runs at 50 MByte/s on a 100 MHz Philips 
TriMedia processor, a 32-bit VLIW processor capable of executing up to 5 op- 
erations in parallel |E^. This is more than three times faster than WAKE in 
OFB mode. It is a challenge for the designer of new cryptographic primitives to 
exploit this parallelism in an optimal way, without compromising security. 

An additional way to exploit parallelism inherent in many algorithms is 
single-instruction, multiple-data (SIMD) processing. A SIMD instruction per- 
forms the same operation in parallel on multiple data elements, packed into a 
single processor word. Tuned to accelerate multimedia and communications soft- 
ware, these instructions can be found in an increasing number of general-purpose 
processor architectures. Examples are Intel’s MMX UltraSPARC’s VIS |HS|, 
PA-RISC 2.0 architecture’s MAX gZ], Alpha’s MVI |Z2|, and MIPS’s MDMX 
■ MMH |331 is an example of a MAC taking advantage of this newly emerging 
technology (cf. 
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The problem of accessing slow memory becomes more and more important 
as the memory access time seems to decrease more slowly than the cycle time 
of the processors. This suggests that faster cryptographic primitives will make 
use of logic and arithmetic operations available on a standard processor and of 
relatively small S-boxes, i.e., typically a few Kbyte in order to fit in the primary, 
on-chip cache. Opening up new perspectives is the recent trend to include ever 
larger secondary caches on a dedicated bus limiting latency to a minimum. The 
advantage of S-boxes is that they can yield a strong nonlinear relation between 
input and output. S-boxes with 8 input bits and 32 or 64 output bits seem to 
be particularly suited for the current 32-bit or 64-bit architectures. 

Other, less important aspects which influence software performance are word 
size, byte ordering (“endianness” m), and carries, which tend to be processor 
dependent. Running an algorithm on a processor that has a smaller word size 
than that of the algorithm will normally result in reduced performance, as it 
requires more instructions to do the same operations. On a processor having a 
larger word size than that of the algorithm advantage might be taken of the new 
SIMD instructions, if available. Byte ordering influences performance if endian- 
sensitive operations are used (like add, multiply, and rotate over non-multiples of 
8) and the processor doesn’t support the kind of addressing mode the algorithm 
requires. In that case an explicit conversion between little and big endian order is 
needed on all input and output data. Moreover, this overhead becomes relatively 
more important as the algorithm becomes faster. However, the use of endian- 
neutral operations (like Boolean operations), possibly in combination with table 
lookups, allows for the algorithm description to be adapted to the byte ordering 
convention of the particular processor the algorithm is run on. This involves 
e.g., redefining the lookup tables and adapting the selection of address bits for 
lookup purposes. In that case the algorithm performance is independent of the 
byte order. All algorithms either use endian-neutral operations or specify the 
endian-convention to be employed, except for SEAL. SEAL uses endian-sensitive 
operations and outputs 32-bit words, but its description US! does not specify a 
particular endian convention. Instead it is suggested to allow either convention 
and to include in SEAL-encrypted ciphertext information indicating the endian 
convention used. 

No such thing as “the software performance” of a given algorithm exists, 
even if figures are given for a specific processor. The key is again the use of 
memory: very different results are obtained depending on whether the data re- 
sides in (level 1 or level 2) cache memory, in main memory, or on disk. On the 
other hand, one wants to measure the performance of the algorithm rather than 
of the computer. Other factors influencing the performance of an algorithm’s 
implementation include: 

— equivalent representations and the use of tables: this can yield significant 
speed-ups, mainly for algorithms which are not designed specifically for soft- 
ware. 

— quality of the compiler: for high level languages, good compilers (with the 
right optimizations activated) can produce code which is almost an order of 
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magnitude faster; hand coded assembly language sometimes results in signif- 
icant improvements by using processor instructions such as rotate which are 
not implemented in languages such as C, by optimizing the use of registers, 
and by exploiting more efficiently instruction-level parallelism. 

One can ask the question whether one should try to optimize the design to- 
wards a single processor: designing and reviewing a cryptographic algorithm will 
take several years, and by that time the processor will probably be outdated. 
But, most processors are downward compatible, and if one tunes an algorithm 
to a recent processor without exploiting particular features (such as the avail- 
ability of certain carries), it is very likely to achieve a high speed on most other 
processors as well (SEAL is a good example, cf. infra). Finally, it should be 
noted that the evolution of processors on smart cards is significantly slower than 
that of general purpose processors. Therefore, there is still an interest in new 
algorithms for ‘old’ processors. 

Table □ gives an overview of the speed of the most important algorithms. 
In order to measure as much as possible the performance of the algorithm (and 
not of the compiler or of the computer used), and in order to compare the 
algorithms on an equal basis, it was decided to implement all the algorithms 
on a single, widely used processor, a (90 MHz) Pentium. The most important 
features of the Pentium are a complex instruction set, a 32-bit word size, a 
small register set of 7 general-purpose registers, little-endian addressing, a 2- 
way superscalar architecture, and separate on-chip code and data caches of 8K 
each. All implementations have been written in assembly language, and all of 
them have been optimized to the same (high) level. A comparison of the CISC 
(Complex Instruction Set Computer) Intel Architecture with the most popular 
RISC (Reduced Instruction Set Computer) architectures (MIPS IV, PA-RISC 
2.0, PowerPC, SPARC V9, Alpha EV5) learns us that the Pentium can to a 
certain extent be considered as a lower bound: current RISC features include 
64-bit word size, at least 31 general-purpose registers, provisions for both little 
and big-endian addressing, and up to 32K of primary (data) cache. Algorithms 
doing well on the Intel Architecture are expected to do well on any modern, 32-bit 
processor d. An important exception are algorithms using a rotate instruction, 
which is not available on all RISC architectures. 

Most algorithms, despite the fact that their operations are basically serial 
in nature, contain enough instruction-level parallelism to keep both execution 
units of the Pentium busy for most of the time. Some algorithms, e.g., SHA-1 and 
RIPEMD-160, contain even more parallelism than most current general-purpose 
processors are able to provide d- More implementation details concerning the 
MD4-family of hash functions can be found in Pd- Only Khufu contains 
hardly any instruction-level parallelism, so that its performance does not bene- 
fit much from having parallel execution units. Also the inherent parallelism of 
SEAL is limited, but it is nevertheless remarkably fast on the Pentium, which 
is explained by the fact that it was tuned by its designers to be fast on 80x86 
processors (use of registers, choice and scheduling of operations). In response to 
the attack of m two additional exors for each 16 bytes of output have beenq 
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Table 1. Performance in clock cycles per block of output and Mbit/s of several 
additive stream ciphers, hash functions, and block ciphers on a 90 MHz Pentium. 
All implementations are written in assembly language, and their level of optimization 
is comparable. Code and data are assumed to reside in the on-chip caches (except for 
Snefru, Tiger, and SHARK, that require more data memory than the 8K of the primary 
data cache). Only the required memory for tables is listed. Some algorithms require 
additional memory for storing the state and possibly the round keys. 



Algorithm 


Rounds 


Block 


Word 


Endian- 


Tables 


Performance 




or (Steps) 


(bits) 


(bits) 


ness 


(bytes) 


(cyc./blk) 


(Mbit/s) 


(alleged) RC4 




8192 


8 


n.a. 


256 


6711 


110 


SEAL 3.0 




8192 


32 


select. 


3K+16/1K 


3727^ 


198“ 


MD2 


18 


128 


8 


n.a. 


256 


2709 


4.25 


MD4 


(48) 


512 


32 


little 


none 


241 


190.6 


MD5 


(64) 


512 


32 


little 


none 


337 


136.2 


RIPEMD-128 


(2 X 64) 


512 


32 


little 


none 


592 


77.6 


RIPEMD-160 


(2 X 80) 


512 


32 


little 


none 


1013 


45.3 


SHA-1 


(80 -h 64) 


512 


32 


big 


none 


837 


54.9 


Snefru-128 


8 


384 


32 


neutral 


16K 


5730^ 


6.03 


Snefru-256 


8 


256 


32 


neutral 


16K 


5738*' 


4.02 


Tiger 


24-h2 


512 


64 


little 


8K 


1320^ 


34.9 


Blowfish 


16 


64 


32 


big 


4K 


158 


36.5 


CAST 


16 


64 


32 


big 


4K 


220 


26.2 


DES 


16 


64 


32 


neutral 


2K 


340 


16.9 


3DES 


48 


64 


32 


neutral 


2K 


928 


6.20 


IDEA 


8.5 


64 


16 


big 


none 


590^ 


9.75 


Khufu 


32 


64 


32 


neutral 


4K 


132 


43.6 


RC5-32/12 


12 


64 


32 


little 


none 


15U 


38.1 


RC5-32/16 


16 


64 


32 


little 


none 


199'' 


28.9 


SAFER K-64 


6 


64 


8 


n.a. 


512 


258 


22.3 


SAFER SK-64 


8 


64 


8 


n.a. 


512 


338 


17.0 


SAFER (S)K-128 


10 


64 


8 


n.a. 


512 


418 


13.8 


SHARK 


6 


64 


64 


neutral 


16K 


585^ 


9.85 


RC5-64/24 


24 


128 


64 


little 


none 


830^ 


13.9 


SQUARE 


8 


128 


32 


neutral 


4K 


244 


47.2 



“ Figures are for a little endian convention. Big endian overhead amounts to 384 cycles 
per 1024 byte block, resulting in a reduced throughput of 179 Mbit/s. 

The tables are twice as large as the on-chip cache. If all used data were cached, 
Snefru’s performance would more than double (to 2674 and 2682 cycles, respectively). 
The tables are equally large as the on-chip cache. Additional memory is required for 
the state (48 bytes), a copy of the data (64 bytes), and the data buffer. Completely 
cached data would improve performance by nearly 30% (1033 cycles, or 44.6 Mbit/s). 

Performance suffers from the slow integer multiplication taking 9 cycles. A 1-cycle 
multiply would almost double the speed of IDEA (to 318 cycles). 

® For RC5-32/r: 7 + 12r cycles per input block. 

^ The tables are twice as large as the on-chip cache. If all used data were cached, 
performance would improve with more than a factor 4 (133 cycles, or 43.2 Mbit/s). 

® For RC5-64/r: 14 -|- 34r cycles per input block. 
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added making SEAL 3.0 [El about 3.6% slower than the original SEAL 1.0 [7^. 
Algorithms with word sizes larger than 32 bits (e.g., SHARK, RC5-64/24, and 
Tiger) will perform relatively better on 64-bit architectures. The SHARK imple- 
mentation has the additional disadvantage on a Pentium of having tables that 
are too large to fit into the on-chip data cache, a property it shares with Snefru. 
Tiger has tables equally large as the on-chip cache, but this is still a problem, 
as additional memory is required for the state, a copy of the input data, and the 
data buffer itself. IDEA suffers from the Pentium’s slow integer multiplication 
(9 cycles), but a 1-cycle multiply would still only result in a doubling of the 
speed, highlighting the fact that IDEA is more than just integer multiplications. 
An interesting alternative is an IDEA implementation using the SIMD MMX- 
instructions, providing both a fast and parallel (but unfortunately only signed) 
multiplication. Such an implementation requires in the order of 360 cycles per 
64-bit block, being about 1.6 times faster than a Pentium only implementation 
m It is also shown that by fully exploiting the SIMD parallelism of MMX up 
to 4 instances of IDEA can be run in parallel, reducing the number of cycles per 
instance to about 135. Some algorithms (e.g., Snefru and SHA-1) will perform 
relatively better on processors having a large register set, such as most RISC 
processors: this enables the complete internal state to be kept in registers. Most 
figures of Table d confirm or improve upon those mentioned in IS2I, except for 
IDEA, where the authors confirmed that their figure of 400 cycles should only 
be considered as a very cursory lower bound, that has not been substantiated 
by an implementation Ell- 

Running these implementations on a PentiumPro or a Pentiumll will not 
necessarily result in the same relative speeds: some implementations heavily rely 
on reading a 32-bit register shortly after having written to an 8-bit subset of the 
same register. On the successors of the Pentium this results in so-called partial 
register stalls, each of which accounts for at least 7 cycles, hence degrading 
performance considerably. 

7 Conclusions 

At present, it is not possible to design a additive stream cipher, hash function, 
or block cipher which is both very fast and ‘secure’. This can be summarized in 
the following quotes: 

L. O’Connor: “Most ciphers are secure after sufficiently many rounds.” 

J.L. Massey: “Most ciphers are too slow after sufficiently many rounds.” 

Some progress has been made into the direction of provable security, often at 
the cost of performance. What does exist however, is provable insecurity, i.e., for 
some designs, serious weaknesses have been identified. 

Given the fact that most fast designs are still developed in a ‘trial-and- 
error paradigm’ and that very little evaluation effort is available, the reader is 
cautioned against adopting new cryptographic primitives too quickly. While the 
cryptographic community has made significant progress during the last twenty 



122 



Bart Preneel, Vincent Rijmen, and Antoon Bosselaers 



years, our knowledge is still very limited; existing cryptanalytic results should 

be evaluated with great care, even if they are only of theoretical nature. 
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A List of Primitives 

This appendix lists selected additive stream ciphers, hash functions, and block 
ciphers and their properties. For the additive stream ciphers and block ciphers, 
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the best attack which is currently known is indicated. The primitives are listed 
in alphabetical order. 

A.l Additive Stream Ciphers 

The following abbreviations are used: 
k key length (in bits) 

I length of the key-stream produced in one iteration (in bits) 

Below the additive stream ciphers: 

(alleged) RC4: k = 8 to 2048, I = 8. The memory consists of one table, 
containing the 256 possible values of a byte. A class of weak keys for RC4 
has been identified m Recently a statistical weakness in the key-stream 
has been exploited P2|. 

SEAL: k = 160, I — 128 f/4l/h) . The memory consists of 2 tables with respec- 
tively 512 and 256 32-bit words, 1 table containing 16 bytes for every 1 Kbyte 
of output, and four registers. The best attack on SEAL uses 2^^ samples of 
the key-stream to determine parts of the key dependent table El- 
WAKE: k = 128, I = 32 j20|- The memory consists of a table with 256 32-bit 
words and four registers. The original WAKE was later renamed WAKE- 
CFB, and can be broken with a differential attack. WAKE-OFB has been 
proposed; no attacks are known. WAKE-OFB has been extended to Wider- 
WAKE in lig. 



A. 2 Hash Functions 

The following abbreviations are used: 

n length of hash result (in bits) 
m length of message blocks (in bits) 

R number of rounds 
S number of steps 

Below the list of hash functions. For a more extensive list and a reference to the 
best known attacks, the reader is referred to ESI- 

MD2: n = 128, m = 128, R = 18 

MD4: n = 128, m = 512, S' = 48 Extended MD4: n = 256 and S = 2 x 48. 

MD5: n = 128, m = 512, S = 64 |7T]. 

RIPEMD-128: n = 128, m = 512, S = 2 x 64 |12l27j . 

RIPEMD-160: n = 160, m = 512, S = 2 x 80 |12l27j . 

SHA-1: n = 160, m = 512, S = 80 (-1-64 operations on data words) j30j . 
Snefru: n = 128 or 256, m = 512 — n, R > 8 [57j . 

Subhash: n = 128, m = 32, R = 8 |2^. 

Tiger: n = 192, m = 512, i? > 24 |^. 
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A. 3 Block Ciphers 

The following abbreviations are used: 

I block length (bits) 
k key length (bits) 

R number of rounds 

F or U the type of the block cipher: F stands for Feistel network, U stands for 
uniform transformation 

For theoretical attacks the work for the required plaintext-ciphertext pairs is not 
counted. 

Blowfish: 1 = 64, k< 448, i? = 16, F jH0|. 

Blowfish uses key dependent S-boxes. If the boxes are known, there is a dif- 
ferential attack m that works for a fraction of 2 of the keys. It requires 
2®^ chosen plaintexts, a memory of 2^^, and an effort of about 2®^ encryp- 
tions. The attack breaks eight rounds for any key with 2^® chosen plaintexts, 
a memory of size 2®^, and an effort of about 2"^® encryptions. A key recovery 
attack on four rounds is described in inni. 

CAST: l = 64,k = 64 to 128, i? = 8 to 16, F mm- 

CAST is actually a design procedure. Ciphers designed according to this 
procedure inherit its name. An attack on eight rounds is described in ftiD) 
The attack requires 2®^ chosen plaintexts. For CAST jll4) with 16-bit round 
keys the attack requires a memory of size 2^®, and an effort of about 2^® 
encryptions. For CAST with 32-bit round keys or 37-bit round keys [21 this 
becomes a memory of size 2®^ or size 2®^, and an effort of about 2®® or 
2®® encryptions respectively. For versions reduced to six rounds, the attack 
becomes very practical. 

DBS: I = 64, k = 56, R = 16, F [2^. 

The best theoretical attack is the linear attack , requiring 2^^® known 
plaintexts, a memory of size 2^® and an effort of about 2^® encryptions. 
Because of the short key, exhaustive key search is feasible. 

FEAL: 1^64, k = 64, R = 8, 16, 24, or 32, F |H3. 

The best attack on eight rounds is a differential- linear attack Q. It requires 
12 (twelve) chosen plaintexts, 2^® bytes of memory and has a workload of 35 
days computer time. The versions with 16, 24, or 32 rounds are vulnerable 
to a differential attack that requires 2®®, 2"^®, or 2®^ chosen plaintexts and 
has a workload of 2®®, 2^®, or 2®^ encryptions jS]. The 16-round and 24-round 
versions are also vulnerable to a linear attack, requiring 2^® or 2^® known 
plaintexts m- The differential attacks also apply to FEAL-NX m- 
GOST: I = 64, k = 256, i? = 32, F (E)- The S-boxes of GOST are not specified. 
The only published attack is a related key chosen plaintext attack PS]- The 
probability of the differential characteristic depends on the S-boxes. Over a 
large set of randomly selected S-boxes this probability varies between 2“"^® 
and 2“®® for a characteristic that may be used in an attack on twelve rounds. 
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IDEA: I = 64, k = 128, R = 8(8.5), F (generalized). The output transformation 
is sometimes counted as an extra half-round m- 

The best attack is a truncated differential attack on three rounds including 
the output transformation m- 1% of the keys can be recovered using 2'^^ 
chosen plaintexts, a memory of 2^® and an effort of about 2®^ encryptions. 
To find 31% of the keys, 2^® chosen plaintexts are required, the same amount 
of memory and an effort of 2®® encryptions. 

Khafre: / = 64, fc = 64 or 128, i? = 16, 24, 32, . . ., F [^3 . 

The best attack is a chosen plaintext attack on 24 rounds |E| . It requires 2®® 
chosen plaintexts, a memory of 2®, and one hour computer time. 

Khufu: ; = 64, fc < 512, R = 16, 24, 32, . . ., F jSSj. 

The best attack is a chosen plaintext attack on 16 rounds m- It requires 2^® 
chosen plaintexts, a memory of 2^®, and an effort of about 2^® operations. 
LOKI91: Z = 64, fc = 64, = 16, F P3|. 

The best chosen plaintext attack on LOKI91 breaks 13 rounds pni- K re- 
quires 2®® chosen plaintexts. The memory requirements are negligible and 
the effort is about 2^® encryptions. The best known plaintext attack breaks 
12 rounds m- It requires 2®® known plaintexts, a memory of 2^®, and an 
effort of about 2®® encryptions. 

MISTY: I = 6A, k = 128, i? = 8, 12, F (generalized) |SS|. There are actually 
two MISTY algorithms: MISTYl is an eight-round Feistel cipher with a new 
kind of key addition, MISTY2 has a more generalized Feistel structure and 
has 12 rounds. 

To the best of our knowledge, no attacks have been published. 

RC5: Everything is variable. The “nominal” values for the parameters are I = 
64, k = 128, R = 12, U jZ2]. Every round of RC5 is composed of two ‘almost’ 
Feistel rounds. 

The best attack on this version is a chosen plaintext attack m- It requires 
2®^ chosen plaintexts and a small amount of memory and work. For some 
weak keys, these numbers are reduced. If I is increased to 128, an attack on 
24 rounds would need 2^^® chosen plaintexts. 

REDOC-II: l^70,k = 70,R^ 10, U EH. 

The best attack is a chosen plaintext attack on four rounds jH|. It requires 
2®® chosen plaintexts and a memory of size 2^®. 

SAFER: I = 64, fc = 64 or 128, i? = 6, 8, or 10, U [50111 . Currently there 
are four versions of SAFER published: SAFER K-64 has A: = 64 and i? = 6, 
SAFER SK-64 has A: = 64 and R = 8, SAFER K-128 and SAFER SK-128 
have k = 128 and R — 10. 

The key scheduling of the K versions has a weakness P2). The best attack 
is a truncated differential attack on five rounds of SAFER K-64 P3|. It 
requires 2^^® chosen plaintexts, a memory of 2®^ and has a workload of 2^*^® 
encryptions. The attack also recovers 32 key bits of SAFER K-128, reduced 
to five rounds. 

SHARK: Z = 64, A; = 64 to 128, R > 6, U [HZ!. 

The best attack is a structure attack on three rounds. It requires 2® chosen 
plaintexts, a memory of size 2® and has a workload of 2®^ encryptions. 
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SQUARE: I = 128, k = 128, i? > 8, U ESEHl- 

The best attack is a structure attack on six rounds m- It requires 2^^ chosen 
plaintexts, a memory of size 2^^ and has a workload of 2^^ encryptions. 
3DES: I = 64, k = 112 or 168, R = 48, F. 3DES consists of three DES encryp- 
tions in cascade. The three DES operations can use three different keys, or 
the first and the last key can be equal m 

The best attack on three-key 3DES is the meet-in-the-middle attack: it uses 
two known plaintexts, a memory of 2®®, and has a workload of 2^^^ encryp- 
tions. The best chosen plaintext attack on two-key 3DES requires 2®® chosen 
plaintexts, a memory of size 2®®, and has a workload of 2^® encryptions 1551 . 
The best known plaintext attack involves a trade-off When given 2" 
known plaintexts, it requires a memory of 2®® and a work effort of about 
2 i 20 -n encryptions. See m for more details on multiple encryption. 

3- WAY: Z = 96, fc = 96, i? = 11, U |21. 

To the best of our knowledge, no attacks have been published. 
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Abstract. We give a brief introduction to elliptic curve public- key cryp- 
tosystems. We explain how the discrete logarithm in an elliptic curve 
group can be used to construct cryptosystems. We also focus on prac- 
tical aspects such as implementation, standardization and intellectual 
property. 



1 Introduction 

Elliptic curves have been studied by mathematicians for more than a century. An 
extremely rich theory has been developed around them, and in turn they have 
been at the basis of new developments in mathematics, the proof of Fermat’s 
last theorem being the most notable one. As far as cryptography is concerned, 
elliptic curves have been used for factoring HSI and primality proving 0. 

Elliptic curve public-key cryptosystems (ECPKCs) were proposed indepen- 
dently by Victor Miller m and Neil Koblitz m in the mid-eighties. As with 
all cryptosystems, and especially with public-key cryptosystems, it takes years 
of public evaluation before a reasonable level of confidence in a new system is 
established. ECPKCs seem to have reached that level now. In the last couple of 
years, the first commercial implementations are appearing, as toolkits but also 
in real-world applications, such as email security, web security, smart cards, etc. 
An overview of theoretical and practical aspects of ECPKCs can be found in 

H- 

In the remainder of this article, we first describe the elliptic curve group 
and explain how public-key cryptosystems can be based on it. Then we continue 
with some more practical aspects, such as implementation, standardization and 
patents. 
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2 The Elliptic Curve Group 

An elliptic curve is the set of solutions of an equation of the form 
+ a\xy + a^y = + a2X^ + a^x + ae . 

An equation of this kind can be studied over various mathematical structures, 
such as a ring or a field. For our purposes, we will only consider elliptic curves 
over a field. In this case, the coefficients Ui are elements of the field, and we look 
at all pairs (x, y) that satisfy the equation, with x and y in the field. 

Figure^gives an example of an elliptic curve over the field of real numbers ffi. 
This graph can be obtained by filling in values for x, and solving a quadratic 
equation in y. In this particular case, the graph consists of two distinct parts, 
but this is not always the case. 

It turns out that the set of solutions of an elliptic curve has some interesting 
properties. In particular, a group operation can be embedded in this set, and in 
this way, we obtain a group, which enables us to do cryptography, as we will see 
in Sect. 0 

A group is a mathematical structure, consisting of a set of elements G, with 
a group operation o defined on the elements of the set. In order to have a group, 
the operation o must satisfy the following properties: 

— closure: for all x, y in G, x o y must be in G; 

— associativity: for all x, y and 2 in G, we must have {x o y) o z = x o (y o z); 

— identity: there exists an e in G such that xo e = eo x = x for all x\ 

— inverse: for all x there exists a y such that xoy = yox = e. 

If on top of that, we have the abelian property: 

— abelian: for all x, y in G, we have x o y = y o x, 
then we say that the group is abelian. 

Is it possible to turn the set of points on an elliptic curve into a group? The 
answer is positive, but how should we define an operation on curve points, with 
the properties mentioned above? This can be done as follows. Take two points 
on the curve, denoted with Pi and P2, and construct the line through these two 
points. In the general case, this line will always have a third point of intersection 
with the curve. Now take this third point and construct a vertical line through 
it. The other point of intersection of this vertical line with the curve is defined 
as the sum of Pi and P2- If Pi and P2 are equal, then the line to be constructed 
in the first step is the tangent to the curve, which again has exactly one other 
point of intersection with the curve. This group law is illustrated in Fig.Q Note 
that the group is abelian; additive notation is often used for the group law of an 
abelian group. 

An important question that still needs to be answered is what the identity of 
the group is. For example, in Fig. 0 what point should be added to P3 to obtain 
P3 as the sum? We can only find an answer to this question if an extra point 
at infinity O is added to the curve, which lies infinitely far on the vertical axis. 
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Fig. 1. Example of an elliptic curve over the reals, and demonstration of the 
group operation 



This point O is the identity of the elliptic curve group. Now, it can be shown 
that this operation is a properly defined group operation, although some of the 
requirements (e.g., associativity) are far from trivial to prove. 

For applications in cryptography, it is not very practical to construct the 
result of a group operation in a graphical way. However, it is possible to find a 
closed formula that gives the coordinates (xs,ys) of the sum Ps of two points 
Pi and P2 as a function of their coordinates (xi^yi) and (x2,y2)- For the case 
of real numbers, the curve equation can be simplified to the form 



y^ = x^ + ax + b . 




134 



Erik De Win and Bart Preneel 



Then the formulas for the group operation are: 



xs = — xi — X2 ; 

ys = A(a;i - xs) - yi ; 



A = 



I 





X2 — Xi 



These equations hold except for the trivial cases where P\ or P 2 are equal to the 
point at infinity, or where —P\, which has coordinates (xi, — j/i), is equal to P 2 - 

A disadvantage of using the real numbers for cryptography is that it is very 
hard to store them precisely in computer memory, and to predict how much 
storage we will need for them. This problem can be solved by using finite fields, 
i.e., fields with a finite number of elements. Since the number of elements is finite, 
we can find a unique representation for each of them, which allows us to store 
and handle the elements in a manageable way. The number of elements of a finite 
field (or Galois field) is always a positive prime power p”; the corresponding field 
is denoted GF(p"). Two special cases are popular for use in EGPKGs: fields of 
the form GF(p) (or n = 1), and fields of the form GF(2"), or p = 2. We will 
discuss both fields in more detail in Sect.0 In a recent paper 0, the use of fields 
of the general form GF(p”) is suggested; we will not discuss these fields here. 

Finite fields are hard to represent in a graphical way, and hence we have to 
rely on formulas for the group operation. For GF(p), the formulas are the same 
as for the reals; for GF(2") they are slightly different (see Sect.|3). 

3 Elliptic Curve Public-Key Cryptosystems 

Many public-key cryptosystems are based on the discrete logarithm problem 
(DTP) in a group. We will give some examples for arbitrary groups, and then 
restrict our attention to elliptic curves. 

The DTP in a group G,o can be defined as follows. Suppose that x and y 
are elements of G and that y was obtained by repeatedly applying the group 
operation to x, i.e., y = x o x <> . . . o x, where the number n of terms in the 
righthand side of the equation is unknown. Alternatively, we note y = x^ . Then 
the DTP consists of finding n, knowing only x and y and the properties of the 
group. 

How easy it is to solve the DTP depends on the properties of the group 
G. In a general group, without extra properties that allow for ‘shortcuts’, the 
DTP is a hard problem, in the sense that the complexity of the best known 
algorithms is approximately equal to the square root of the size of the group. 
However, a number of interesting groups have additional structure that enable 
the application of faster algorithms, making these groups less suitable (but not 
necessarily useless) for cryptography. 
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The Diffie-Hellman key agreement protocol is an example of how a public-key 
cryptosystem can be constructed based on the DLP in a group (see also Fig. 0 . 
Traditionally, the parties in the protocol are called Alice and Bob. 



Alice 

choose a, compute g°‘ 



compute (g*’)“ = = K 



g” 



Bob 

choose b, compute 



compute = g°'^ = K 



Fig. 2. Diffie-Hellman key agreement protocol 



Setup Alice and Bob agree on a common group G and a common group element 
g. Then Alice chooses a secret number a, which serves as her secret key, and 
Bob chooses a secret key b. 

Communication Alice computes and sends it to Bob over a public channel; 
Bob sends to Alice. Although g°‘ and g^ are closely related to a and b 
respectively, the hardness of the DLP ensures that the secret keys cannot 
be computed from them in a practical situation. Therefore, 5“ and g^ can 
serve as public keys, corresponding to the private keys of Alice and Bob 
respectively. 

Final step Alice takes Bob’s public key and computes = g°“^] Bob com- 
putes = 5“^. As we see, Alice and Bob obtain the same result, and this 
result could not be computed by an adversary who only knows the public 
keys. Therefore Alice and Bob have agreed on a shared secret key. 

Note that precautions need to be taken to make this protocol secure against 
both passive and active attacks. Describing them here would lead us to far; more 
details can be found in for instance. Also, note that hardness of the DLP 
does not guarantee the security of the Diffie-Hellman protocol: computing g°“^ 
from g°“ and g^ may be easier than computing a from g°‘ or b from g^. 

Up to now, we have not specified the particular group we are working in. 
Interesting candidates are groups where the DLP is hard to solve. Examples of 
groups that have been used for about 20 years are the multiplicative groups of 
finite fields, in particular Zp, • and GF(2"), •. A number of shortcuts have been 
found to solve the DLP in these groups in sub-exponential time, but they are 
still practical for use in cryptography. Examples of public-key systems based on 
the DLP in Zp, • are ElGamal signatures, ElGamal encryption and DSA [TTlj . 
where p is usually taken to be at least 1024 bits long for security reasons. 

In the mid-eighties, Victor Miller PH and Neal Koblitz P2] independently 
proposed to use the group of an elliptic curve over a finite field for public-key 
cryptography. No shortcuts were known to solve the elliptic curve DLP (EGDLP) 
faster than in time proportional to the square root of the group size, and up to 
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now, this is still the case, except for a number of degenerated classes of curves 

mm- 

All DLP-based cryptosystems can be converted to elliptic curves, and so we 
have ECDSA, EC Difhe-Hellman, EC ElGamal encryption, etc. Some slight tech- 
nical modifications are necessary in order to adapt to the elliptic curve setting, 
but the underlying principles are the same as for other DLP-based systems. 



4 Comparison to Other Public-Key Cryptosystems 

How do elliptic curve public-key cryptosystems compare to other popular sys- 
tems such as their counterparts based on the group Zp, • or to systems based on 
integer factorization? 

A very important observation is that the best known algorithms for the 
ECDLP have a complexity proportional to the square root of the group size, 
whereas DLP in Zp, • and integer factorization can be solved in sub-exponential 
time. This implies that, for a certain level of security, the sizes of the parameters 
can be substantially smaller. It is hard to obtain accurate security estimates for 
EC, but experts in the field estimate that an elliptic curve group with a 175-bit 
size has a security that is equivalent to RSA with a 1024-bit modulus, or to 
systems based on DLP in Zp, • with p a 1024-bit prime fZ4\ . 

The smaller block size has important implications on the resources that are 
needed to implement an ECPKC. For example, far less chip area is needed for 
an elliptic curve processor than for an RSA processor. In applications where 
bandwidth is an issue, elliptic curves can also offer an advantage. In elliptic 
curve key agreement protocols, the quantities transmitted are much shorter. An 
elliptic curve signature is only 340 bits long, as opposed to 1024 bits for an RSA- 
signature. Note however that DSA-signatures are only 320 bits long and that it 
is possible to reduce the overhead in storage of an RSA signature by recovering 
part of the message from the signature HH. 

For a comparison of the performance of various public-key cryptosystems 
we refer to Sect. 0 The EC group operation is more complex than the core 
operations of other systems such as RSA, and therefore the smaller block size is 
not reflected proportionally in the performance figures. 



5 Implementation Issues 

In this section we will discuss some aspects of software implementations for 
ECPKCs. The time consuming operation in an ECPKC is the multiplication of 
a point on a curve by an integer, i.e., the repeated group operation, also called 
EC exponentiation, since it is analogous to exponentiation in other discrete 
logarithm-based systems. An implementation of the repeated group operation 
consists of two levels of hierarchy: the group operation level, and the level of 
calculating a point multiplication using single group operations. We will discuss 
both levels in separate paragraphs. 
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Also, in Sect.|2]we saw that in cryptography elliptic curves over two kinds of 
fields are used: GF(p) or GF(2"). We will discuss the group operation for both 
kinds of fields in separate paragraphs. 



5.1 Elliptic Curve Group Operation over GF(p) 

The formulas for the group operation on elliptic curves over GF(p) are given in 
Sect.El From these, the group operation can be calculated in terms of a number 
of field operations, such as addition, subtraction, multiplication and inversion. 
The field GF(p) is usually represented by the integers modulo p, and hence the 
field operations are modular operations, similar to the operations needed in other 
public-key cryptosystems such as RSA or DSA. Therefore, parts of the software 
libraries for the latter can be reused for elliptic curves over GF(p). 

The inversion operation deserves some extra attention. In most public-key 
cryptosystems, modular inversion is not very important, but in EGPKGs it 
turns out to be the major bottleneck if the group operation is implemented 
in a straightforward way. Fortunately, it is possible to reduce the number of 
inversions by representing the points in projective coordinates PI. 

Implementations of elliptic curves over GF(p) have been described in [I and 
p]. Tabledgives typical timings for the field operations and the group operations 
for the GF(p) case. 

5.2 Elliptic Gurve Group Operation over GF(2") 

The elliptic curve equations and formulas for finite fields GF(2”) are slightly 
different. The curve equation can be simplified to 

+ xy = + ax^ + b , 

and the addition formulas are 

xs = -l- A -l- -l- a::2 -l- G , 

ys = X{xi + Xs) + xs + yi , 



with 

yi±]^ if Pi ^ P2 , 

X2 + Xi 

Xx + — \i Pi = P 2 ■ 

Xi 

Gontrary to GF(p), a number of different representations are commonly used 
for the elements of a field GF(2"). The simplest representation is in standard 
basis, where the elements are binary polynomials of degree smaller than n, and 
calculations are done modulo an irreducible binary polynomial of degree ex- 
actly n. Another representation is based on optimal normal bases jl D) . In this 
case, elements are represented as linear combinations of the elements of the set 




138 



Erik De Win and Bart Preneel 



{/3^ ,/3^ ,/3^ , . . . ,13'^" }, where /3 is a suitably chosen element of the field. A 

third representation, sometimes called tower field representation, represents the 
elements as polynomials over the field GF(2’'), where r is a divisor of n. 

A number of implementations of ECPKCs over GF(2") have appeared in 
literature, based on these three representations; see [415171812.^ . Table ^ gives 
typical timings for the field operations and the group operations for GF(2") 
using a standard basis. 



Table 1. Timings for field operations over GF(p) and GF(2") on a PPro200. 
A standard basis is used for the latter. The field size is approximately 191 bits 
for both. All times in ^s. 





GF(p) 


GF(2"-) 


addition 


1.6 


0.6 


multiplication 


7.8 


39 


squaring 


7.6 


2.6 


inverse 


180 


126 


EC addition 


103 


215 


EC double 


76 


220 



5.3 Point Multiplication 

As soon as we have algorithms for the group operation available, we want to 
look for a method that computes a point multiplication using as little group 
operations as possible. This corresponds to the problem of computing an expo- 
nentiation using multiplications in other cryptosystems such as RSA or DSA. 

A very simple algorithm for this is the square-and-multiply algorithm, see 
e.g., Hm. A number of optimizations to this algorithm are possible; |S| gives a 
good overview. An advantage of elliptic curves is that the inverse of a point can 
be computed very efficiently (see Sect. 0 ). A comparison of different algorithms 
using this optimization can be found in |^. 

With the algorithms for point multiplication, we can start building various 
public- key schemes. Table |2| compares the efficiency of signature schemes based 
on elliptic curves to other signature schemes. 

6 Standardization 

It took a number of years before manufacturers of cryptographic products at- 
tained confidence in elliptic curve systems, but we seem to have reached that 
point now. A number of standardization bodies are undertaking efforts to cre- 
ate standards about elliptic curves. Although none of them have been officially 
approved yet, most are quite mature and not expected to change much before 
approval. 
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Table 2. Comparison of ECDSA to other signature algorithms. For EC, the 
field size is approximately 191 bits. The modulus for RSA and DSA is 1024 bits 
long; the RSA public exponent is 3. All times in ms, unless otherwise indicated. 
The timings were done on a PPro200. 



times in ms 


GF(p) 


GF(2") 


RSA 


DSA 


key generation 


5.5 


11.7 


1 s 


7 


sign 


6.3 


11.3 


43.3 


7 


verify 


26 


60 


0.65 


28.3 


general point multiplication 


21.1 


56 







A broadly known initiative for a public-key standard, including ECPKCs, 
is the IEEE P1363 working group, to which the authors have also delivered 
a number of contributions. More information, including the latest draft and 
directions on how to join the mailing list, can be found at the web site m- 

The ANSI X9F1 working group is also working on a number of documents 
including elliptic curve-based systems, in particular X9.42 (DH/MQV key agree- 
ment), X9.62 (elliptic curve signatures) and X9.63 (elliptic curve key agree- 
ment/transport). More information can be found at j2bj . 

Other organizations working on elliptic curve standards are ISO/IEC and 
the Internet Engineering Task Force. 

7 Intellectual Property Issues 

Contrary to RSA, the basic idea of ECPKCs has not been patented, and in the 
beginning this seemed to be an important advantage. In the past two years, 
a number of patents have been applied for on techniques that mostly aim at 
improving the efficiency. It should be noted that the situation is rather unclear 
since most of these patents are still pending. In principle, it should still be 
possible to construct a secure, albeit not extremely efficient, ECPKC without 
licensing patents. 

A number of these techniques are being considered for inclusion in stan- 
dards and this will potentially make it hard to implement interoperable elliptic 
curve systems without licensing patents. On the other hand, some standardiza- 
tion organizations require the holders of patents on standardized techniques to 
guarantee ’reasonable’ licensing conditions. In summary, elliptic curves have lost 
many of their advantages as far as patents are concerned, but the situation is 
probably not worse than for other popular public-key systems. However, this 
may change when the RSA patent expires on Sept. 20, 2000. 

8 Couclusiou 

Elliptic curve public-key cryptosystems are well on their way to being a serious 
alternative to older public-key cryptosystems, in particular RSA. They can be 
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implemented efficiently, and have a number of advantages that can make them 
the best choice in a range of applications (such as on-line communications and 
wireless communications). With a number of standards being in preparation, 
interoperability between the different products will be much easier to obtain. 
The patent situation is not as nice as it first appeared to be, but it should not be 
an important drawback either. One factor that still remains largely uncertain is 
the security: as with all practically used public-key cryptosystems, their security 
has not been proven but is based on the inability to find attacks. If attacks exist 
on any of these systems, they might be discovered sooner or later. In this case 
it is vital to be able to quickly switch to an alternative. 
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Abstract. Security services based on cryptographic mechanisms assume 
cryptographic keys to be available to the communicating parties prior to secure 
communications. Key management techniques depend on the underlying 
cryptographic techniques, the intended use of the keys and the security policy 
in use. This article describes such techniques, and especially a variety of key 
establishment mechanisms. In addition, relevant standardization activities are 
discussed. 



1 Introduction 

Security services based on cryptographic mechanisms (e.g., data encipherment, 
message authentication, digital signatures) assume cryptographic keys to be 
distributed to the communicating parties prior to secure communications. The secure 
management of these keys is one of the most critical elements when integrating 
cryptographic functions into a system, since even the most elaborated security 
concept will be ineffective if the key management is weak. 

Key management includes the secure generation, registration, certification, de- 
registration, distribution, installation, storage, archiving, revocation, derivation and 
destruction of keying material. Key management techniques depend on the 
underlying cryptographic techniques, the intended use of the keys and the security 
policy in use. The appropriate protection of keys is subject to a number of factors, 
such as the type of application for which the keys are used, the threats they face, or 
the different states the keys may assume. Primarily, depending upon their type, keys 
have to he protected against disclosure, modification, destruction and replay. 

Common cryptographic techniques used for the protection of data can also be used 
for the protection of keying material. E.g., encipherment counters key disclosure and 
unauthorised use of keying material; data integrity mechanisms counter modification; 
data origin authentication mechanisms, digital signatures, and entity authentication 
mechanisms counter masquerade. Cryptographic separation mechanisms counter key 
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misuse, e.g., binding control information to keys can assure that specific keys are 
used for specific operations only (e.g., key encipherment, digital signatures, etc.). 

A large variety of key management mechanisms can be found in the literature (see 
e.g., [MVV96]). Key management techniques have also been addressed by several 
standardization bodies which resulted a variety of national and international 
standards, e.g., for the area of hanking [ANSIX9.17], [ANSIX9.24], [ANSIX9.57], 
[ISOl 1666-x], [ISOl 1568-x], or for the support of network security protocols 
[Orm96], [FKKD96], [MSST97]. Base standards dealing with generic issues of key 
management include [ISO11770-x], and [IEEE1363]. 



2 Key Management Issues 

The fundamental security requirement for every key management system is the 
control of keying material through the entire lifetime of the keys in order to prevent 
unauthorized disclosure, modification, substitution, and replay. Cryptographic keys 
must be randomly generated. In order to protect secret keying material from 
disclosure it must either be physically secured or enciphered. In order to protect 
keying material from modification it must either be physically secured or 
authenticated. Authentication may involve the use of time variant parameters such as 
random challenges, counters or timestamps to also protect from replay of old keys, 
insertion of false keys, and substitution or deletion of keys. 



2.1 Types of Keys 

Different cryptographic techniques use different types of keying material. Secret 
keys are keys used with symmetric cryptographic techniques. They shall be usable 
only by a set of specified entities which are said to „share a key“. 

With asymmetric cryptographic techniques, asymmetric key pairs are used. An 
asymmetric key pair is a pair of related keys where the private key defines the private 
transformation (e.g., signature generation, decipherment) and the public key defines 
the public transformation (e.g., signature verification, encipherment). A private key 
shall only be known by the associated entity. Public keys can be made public. 

Depending on the actual security policy, keys may he labeled according to their 
function so that their use can be reserved for that purpose. 



2.2 Key Life Cycle 

Cryptographic keys progress through a series of states that define a life cycle. The 
three principal states of a key life cycle are: 

• Pending Active: The key has been generated, but has not been activated for use. 

• Active: The key is used to process information cryptographically. 

• Post Active: In this state, a key shall only be used for decipherment or verification. 
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generation reactivation 




destruction destruction 



Fig. 1. Key Life Cycle 

Figure 1 shows a generic key life cycle model. Specific life cycle models may have 
additional details, e.g., substates of the three states presented. When a key progresses 
from one state to another it undergoes one of the following transitions (see figure 1): 

• Key Generation has to be performed according to prescribed key generation rules; 
the process may involve a test procedure to verify whether these rules have been 
followed. 

• Key Activation makes a key valid for cryptographic operations. 

• Key Deactivation limits a key’s active use. Deactivation may occur because a key 
has expired or has been revoked. 

• Key Reactivation may allow a post active key to be used again for cryptographic 
operations. 

• Key Destruction ends a key's life cycle. Destroying a key means eliminating all 
records of this key, such that no information remaining after the deletion provides 
any feasibly usable information about the destroyed key. It covers logical 
destruction of the key and may also involve its physical destruction. 

Transitions between states may be triggered by events such as the need for new keys, 
the compromise of a key, the expiration of a key, or the completion of the key life 
cycle. 



2.3 Key Generation 

Secure key generation implies the use of a random or pseudo-random process 
involving random seeds, which cannot be manipulated. Requirements include that 
certain elements of the key space are not more probable than others and that it is not 
possible for the unauthorized to gain knowledge about keying material. 

There are several ways to acquire or generate random numbers [MVV96], but 
none of them is guaranteed - the existence of true random sources is an assumption. 
Possible sources of unguessable values include quantum effects in semiconductors, 
radioactive sources, air turbulences, coins or dices. There are always some keys (e.g., 
master keys) that should be generated by using such a random process. Before using a 
specific source of entropy for the purpose of key generation it should be verified that 
it is not severely biased. 
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Common software for generating pseudo-random numbers in general is too 
predictable to be used for key generation. Also the use of CD ROMs, random number 
tables, or chaos equations cannot be recommended for generating keying material. 



2.4 Key Life Time 

The validity of keys shall be limited in time and amount of use. Such constraints 
are governed by the time and amount of data required to conduct a key-recovery 
attack and by the strategic value of the secured information over time. E.g., keys that 
are used to generate keys need stronger protection than the generated keys. A key 
shall be replaced within the time deemed feasible to determine it by an exhaustive 
attack. A replaced key shall not be re-used. 

A key is said to be compromised when its unauthorised use is known or suspected. 
The danger of a key being compromised is considered to increase with the length of 
time it has been in operation and the amount of data it has been used to encipher. 
Compromised keys shall be replaced immediately. In addition, they may require 
special handling, e.g., black listing. 



2.5 Key Establishment 

Keys may be established either manually or automatically. Manually distributed 
keys are exchanged between parties independent of the communication channel. They 
shall always be protected using physical security (e.g., sealed envelopes, tamper- 
proof devices) or dual control. Physical channels are typically used to achieve 
confidentiality and authentication jointly. Examples of physical channels for 
authentication only are newspapers and compact discs. When using only symmetric 
cryptographic techniques, at least a first key has to be manually established between 
two parties in order to allow secure communications. 

For almost all systems, it is necessary to devise means to distribute keys over the 
same communication channels by which actual data are transmitted. Secure key 
distribution over such a channel requires cryptographic protection and thus the 
availability of matching keys. This circularity has to be broken through prior 
distribution of a (small) number of keys by different means. For this purpose, in 
general some Trusted Third Party is required. If the mechanisms used are based on 
symmetric techniques, this trusted party typically is called Key Distribution Center. If 
the mechanisms used are based on asymmetric techniques, the trusted party is called 
Certification Authority (CA). 

For an automatic establishment of keys, key tokens are exchanged between 
communicating parties for the transmission of keying material, or for authentication 
purposes. Such tokens may contain keys and additional data, such as the distinguished 
names of entities, key-IDs, counters, or random values. Key tokens have to be 
protected depending on their contents and on the security requirements. Required 
properties for a key establishment technique may include: 
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• Data Confidentiality. Secret keys and possibly other data are to be kept 
confidential while being transmitted or stored. 

• Modification Detection to counter the active threat of unauthorized modification of 
data items. 

• Entity Authentication. Mutual authentication provides both entities with assurance 
of each other's identity while in the case of unilateral authentication only one entity 
is provided with such assurance. 

• Key Freshness, i.e., a guarantee that the established keying material is new, as 
opposed to the reuse of old keying material. 

• Key Control. The ability to choose the key, or the parameters used in the key 
computation. 

• Implicit Key Authentication. The assurance for one entity that only another 
identified entity can possibly be in possession of the correct key. 

• Key Confirmation. The assurance for one entity that another identified entity is in 
possession of the correct key. 

• Perfect Forward Secrecy. A key establishment protocol is said to offer perfect 
forward secrecy if compromise (or release) of long-term keys does not 
compromise past session keys. 

• Efficiency. Considerations include the number of message exchanges (passes) 
required, the number of bits transmitted, and the complexity of computations 
required by each party. 

Many of the important properties of key management protocols do not depend on 

the underlying cryptographic algorithms, but rather on the structure of the messages 

exchanged. Therefore, bugs in key establishment mechanisms usually do not come 

from weak cryptographic algorithms, but from mistakes in higher levels of the design. 



2.6 Key Hierarchies 

One means of protecting keys is to organise them into key hierarchies. Except at 
the lowest level of the hierarchy, keys in one level of a hierarchy are used solely to 
protect keys in the next lower level. Only keys in the lowest level of the hierarchy are 
used directly to provide data security services. This hierarchical approach allows the 
use of each key to be limited, thus limiting exposure and making attacks more 
difficult. Also, the introduction of key hierarchies significantly reduces the number of 
keys that cannot be distributed automatically. 

In every key management system there is a kernel where some physical security 
has to be assumed. This physically protected data usually includes so-called Master 
Keys, which are on the top level of a key hierarchy and therefore cannot be protected 
using other keys. 
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3 Models for Key Establishment 

Key establishment is the process of making available a key to one or more entities. 
Key establishment techniques include secret key agreement and key transport for 
secret, private, and public keys. Additional techniques are key update and key 
derivation. 

For many environments, protocols that allow to establish keying material in one 
pass are of particular interest. If entity authentication is a requirement, typically a set- 
up phase is needed prior to key establishment. 

The establishment of keys can be rather complex. Key establishment protocols are 
influenced by the nature of the communications links, the trust relationships involved 
and the cryptographic techniques used. The entities may either communicate directly 
or indirectly, they may belong to the same or to different security domains, and they 
may or may not use the services of a trusted authority. The following conceptual 
models illustrate how these different aspects affect key establishment. 



3.1 Point- to-Point Key Establishment 

The basic mechanism of every key establishment technique is point-to-point key 
establishment (see figure 2). If based on symmetric cryptographic techniques, point- 
to-point key establishment requires that the two parties involved already share a key 
that can be used to protect the keying material to be established. If based on 
asymmetric techniques, point-to-point key establishment typically requires that each 
of the parties has a public key with its associated private key, and that the 
authenticated public key is known to the other party: 

• For data integrity or data origin authentication, the recipient requires the sender’s 
corresponding public key certificate. 

• For confidentiality, the sender requires a public key certificate of the intended 
recipient. 



Entity A 



Entity B 



Fig. 2. Point-to-Point Key Establishment 



3.2 Key Establishment Within One Domain 

One of the simplest forms of key establishment employs a single Trusted Third 
Party (e.g., a KDC, a CA) for the entire system. This authority may offer key 
management services such as the generation, certification, distribution or translation 
of keying material. When the entities use asymmetric techniques for the secure 
exchange of information, each entity may need to contact its authority to get an 
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appropriate public key certificate. In situations where the communicating partners 
trust each other and can mutually authenticate their public key certificates, no 
authority is needed. 

When symmetric cryptography is in use between two such entities, sender and 
receiver are required to share keys with the authority. Key establishment then is 
initiated in one of two ways: 

• By one entity generating the key and sending it to a Key Translation Center 
(KTC). The KTC receives an enciphered key from one entity, deciphers it and re- 
enciphers it using the key shared between itself and the other entity. Then it may 
either forward directly the re-enciphered key, or send it back to the first entity, 
who forwards it to the second entity. 

• By one entity asking a Key Distribution Center (KDC) to generate a key for 
subsequent distribution. The KDC then either distributes the key directly to both 
entities, or it sends it back to the initiator, who forwards it to the other entity. 



TTP 






Entity B 



Fig. 3. Key Establishment Using a TTP 

For large systems, key establishment usually is organized in a hierarchical way. A 
group of entities served by one authority is called a Security Domain. 




3.3 Key Establishment Between Domains 

The third model involves entities belonging to different security domains (see 
figure 4). By definition, each domain has its own security authority. If A and B either 
trust each other or each entity trusts the authority of the other’s domain, then keys 
may he distributed according to the above model. 

When the entities use asymmetric techniques and do not have access to a common 
directory service that offers public key certificates, each entity shall contact its 
respective authority to get its partner's public key certificate. The authorities of A and 
B may exchange the public key certificates of entities A and B and forward them to A 
and B. A second approach for the exchange of public key certificates is cross- 
certification where the CAs certify the public keys of other CAs. 

When the entities use symmetric techniques, at least one of them has to contact its 
authority to receive a secret key for communication. The authorities then establish a 
common secret key to be used by the entities. This key may be distributed by one 
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authority to both entities using the other authority as a KTC, or via one of the entities 
which is responsible for forwarding the key to the other entity. 



Domain A 



TTP of A 



/ 



Entity A 



Domain B 

TTP of B 

V 

\ 

Entity B | 



Fig. 4. Key Establishment Between Two Domains 

In situations where the authorities of A and B neither have a mutual trust 
relationship nor a direct communications path, they have to involve one or more 
additional TTPs until a chain of trust is established. 



4 Public Key Transport Mechanisms 

Public key transport makes an entity’s public key available to other entities. The 
essential security requirement for the establishment of public keys is key 
authentication which can be achieved with or without a TTP: 

• If an entity has access to a channel which provides data origin authentication and 
data integrity (such as a courier, registered mail, etc.) then it may transfer its public 
key directly via this channel. 

• Alternatively, public keys may be transported via unprotected channels. For data 
origin authentication and data integrity then a second authenticated channel has to 
be used. Such an approach is useful when for public key establishment a high 
bandwidth electronic channel is available, and for authentication a low-bandwidth 
channel (such as telephone, couriers, registered mail, etc.) can be used. 

• In the case of public key establishment using a Certification Authority (CA), the 
authentication of public keys is provided in the form of Public Key Certificates. 
So-called credentials contain the identifying data of an entity together with its 
public key and additional information (e.g., an expiration date). Credentials are 
rendered unforgeable by a digital signature provided by a CA, thus becoming 
certificates. The validity of a certificate can be verified using the CA’s public key 
whose authenticity has to be provided by other procedures. Since verifying the 
validity of a certificate can be carried out without assistance of the CA, the trusted 
party is only needed for issuing the certificates. The exchange of certificates can be 
performed off-line and is not shown in the following protocols. 
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5 Secret Key Transport Mechanisms 

Key transport is the process of transferring a key created or otherwise obtained by 
one entity (e.g., the initiator of the protocol, or a trusted third party) to another entity, 
suitably protected by cryptographic techniques. Secret key transport based on 
symmetric techniques makes use of (long-term) symmetric keys shared a priori 
between sender and receiver. ISO/IEC 11770-2 specifies twelve such mechanisms 
whose major properties are summarized in table 1 [ISO11770-2[]. The first five table 
entries are point-to-point key transport mechanisms, the other mechanisms involve a 
third party. 
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Table 1. Key Transport Mechanisms of ISO/IEC 11770-2 

Secret key transport using public -key techniques assumes that the sender possesses 
a priori an authentic public encryption key of the intended recipient. ISO/IEC 11770- 
3 specifies six generic mechanisms for secret key transport whose major properties 
are shown in table 2 [ISOl 1770-3]. 
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Table 2. Key Transport Mechanisms of ISO/IEC 11770-3 

In the following sections, a number of typical examples for secret key transport 
mechanisms is given. 



5.1 Secret Key Transport Using Symmetric Techniques 

In the basic key transport mechanism illustrated in figure 5 (mechanism 2 of 
[ISOl 1770-2]), the keying material K is supplied by entity A: 



* Mechanism 1 of ISO/IEC 11770-2 is a key derivation mechanism (see section 5), mechanisms 
5 and 6 are key agreement schemes that may be used for key transport. 
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A 



encKAB( K ) 



B 



Fig. 5. Basic Mechanism Using Symmetric Techniques 

1. A sends B the keying material K enciphered with the shared key K^. 

2. B deciphers the message and thus obtains K. 

This basic mechanism only provides implicit key authentication to A. However, 
the mechanism can easily be extended to also provide unilateral authentication of 
entity A, implicit key authentication and a freshness guarantee to B, and protection of 
replay back to A. In the mechanism shown in figure 6 (mechanism 3 of [ISO11770- 
2]), two additional fields are transferred in the enciphered part: 



A 



encKAB( T/N II B II K ) 



B 



Fig. 6. Secret Key Transport with Unilateral Authentication 

1 . A sends B a time stamp T or a sequence number N, the distinguishing identifier b|^ 
and the keying material K. The data fields are enciphered with K^. 

2. B deciphers the message, checks the correctness of its distinguishing identifier, 
checks the time stamp or sequence number, and obtains the keying material K. 

ISO/IEC 11770-2 specifies three additional variants of point-to-point secret key 
transport mechanisms based on symmetric techniques (see table 1). 



5.2 Third Party Secret Key Transport Using Symmetric Techniques 

Third party secret key transport mechanisms based on symmetric techniques 
assume that both entities A and B a priori share a secret key (denoted by and 
respectively) with the TTP. Furthermore, the third party is requested to be on-line 
with at least one of the entities. 

In the following key transport mechanism (mechanism 8 of [ISO 1 1770-2], the 
keying material K is supplied by a Key Distribution Center: 



^ Distinguishing identifier B is included to prevent a so-called substitution attack, i.e., the re- 
use of this message on A by an adversary masquerading as B. 
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1 . A requests keying material from the KDC by sending a message to the KDC that 
contains a time variant parameter TVP^ (a random number, time stamp, or 
sequence number) and the distinguishing identifier of the recipient B. 

2. The KDC returns a protected message to A that contains the keying material K 
enciphered for A and enciphered for B : 

encK„( TVP^ || B || K ) || encK^^C T/N^ || A || K ) 

3. On receipt of this message, A deciphers the first part, checks that the time variant 
parameter sent to the TTP was used in constructing the message, checks the 
distinguishing identifier, and obtains K. If all checks are positive, A forwards the 
second part of the message to B followed by a data field encK( T/N^ II B ) which 
enables B to authenticate A and to check the integrity of the retrieved key K. 

4. B deciphers the message, checks the correctness of the time stamp or sequence 
number, and obtains the keying material K. The distinguishing identifier indicates 
to B that K was requested by A. Then B deciphers the second part of the message 
and checks the correctness of the time variant parameter and of its distinguishing 
identifier. 



A 



TTP 



encK^x) TVP^ || B || K ) | 
encKex( T/N^ || A || K ) 



encKex( T/N^ || A || K ) || encK( T/N^ || B ) 




B 



Fig. 7. Secret Key Transport with TTP 

This mechanism provides entity authentication of A and key confirmation to B. By 
adding a fourth message, it can be extended to provide mutual entity authentication 
and mutual key confirmation [ISOl 1770-2], 



5.3 Point-to-Point Secret Key Transport Using Public-Key Techniques 

ElGamal and RSA key transport are examples for a one-pass key transport 
mechanism based on asymmetric techniques|] For the mechanism shown in figure 8 



^ The following mechanisms can be implemented using any public key encipherment system. 
Candidate techniques include the standard ElGamal system. Elliptic Curve based ElGamal, 
and the RSA system. 
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(mechanism 1 of [ISOl 1770-3]) it is required that A has access to an authenticated 
copy of B’s public encryption key Kg^. 



A 



encKupC T/N || A || K ) 



B 



Fig. 8. ElGamal Key Transport 

1. A sends B a time stamp T or a sequence number N, the distinguishing identifier B, 
and the keying material K. The data fields are enciphered with B ’ s public key Kg^. 

2. B deciphers the received message, checks the correctness of the time variant 
parameter and associates the recovered keying material with A. 

The mechanism provides replay protection and implicit key authentication for A since 
only B is able to recover the key K. In contrast to the analogue mechanism based on 
symmetric techniques, B has no assurances regarding the source of the keying 
material. 

To also provide authentication of the initiator A, the key token typically is signed 
in addition to encipherment: 



A 



encKBp(sigK^,(T/N||B||K)) 



B 



Fig. 9. Key Transport with Originator Signature 

1. A forms a data block consisting of a time stamp or sequence number, the 
recipient’s distinguished identifier, and the keying material K. Then A signs the 
data and enciphers the signature using B’s public encryption key. The result is 
transferred to B. 

2. B deciphers the received message and verifies integrity and origin of the key 
token. Then B validates that he is the intended recipient of the token and that the 
token has been sent timely. If all verifications are successful, B accepts the keying 
material K. 

This mechanism provides replay protection, unilateral entity authentication (based on 
A’s digital signature), and mutual implicit key authentication (since only B is able to 
decipher and only A is able to sign). Depending on the needs of the environment, the 
signature may also be applied after encipherment (see e.g., mechanism 2 of 
[ISOl 1770-3]). 
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6 Key Derivation Mechanisms 

Key derivation mechanisms establish shared keys which is based on per-session 
varying input. 



6.1 Basic Key Derivation Scheme 

In the following basic key derivation mechanism a new shared key K is derived 
from a shared key and a non-secret parameter F using an appropriate key 
calculation function. The mechanism consists of two steps: 

1. The initiator A generates or selects the key derivation parameter F (e.g., a random 
number R, a time stamp T, or a sequence number N) and transfers it to B. 

2. Both A and B then derive the shared key K by using the key calculation function f 
with inputs the shared secret key and the key derivation parameter: 

K = f(K^,F). 

The mechanism provides implicit key authentication. Note that there is a non- 
interactive variant where the parameter F is known a priori to both A and B (e.g., the 
current date). 



6.2 Key Calculation Functions 

Key calculation is a technique for obtaining a secret key from two or more data 
items, at least one of which is secret, using an appropriate key calculation function 
(which may be publicly known). An example for a key calculation function is 
applying a cryptographic hash-function to the concatenation of the data items, e.g., 

K = hash( K^ || X ). 

Key calculation functions are, e.g., specified in several IETF documents. In [Hug96] 
the shared key K established by a key management protocol is used to derive a 
number of shared secrets needed for the security protocol. All keying material is 
derived from K using MD5-based transforms with different 512-bit padding. The 
hash-values are truncated as necessary, e.g., (asymmetric) DES keys are calculated as 
follows [Fu97]: 

K^ = Truncate( MD5( ‘5C5C5C...5C’ || K ), 64 ) 

Kg^ = Truncate) MD5( ‘3A3A3A...3A’ || K ), 64 ) 

Similarly, the Transport Layer Security (TLS) protocol [FKKD96] generates keys, 
IVs, and MAC secrets from the security parameters provided by a handshake 
protocol. Those are a master_secret shared between the two entities in the connection, 
and two random numbers r,, and r^, provided by the client and the server, respectively. 
A combination of two hash-functions is used to expand the security parameters into a 
sequence of shared secrets. To generate the necessary keying material, one computes 
MD5( master_secret || SHA( 'A' || master_secret || r,, || r^, )) || 

MD5( master_secret || SHA( 'BB' || master_secret || r^, || r^ )) || 

MD5( master_secret || SHA( 'CCC || master_secret || r^, || r^ )) || ... 
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until enough output has been generated. Then the data is partitioned and any extra 
keying material is discarded. The TLS handshake protocol uses a similar technique to 
calculate a master_secret of fixed length (48 bytes) from a variable-length 
pre_master_secret [Fu97]. 



6.3 Authenticated Key Derivation 

To also provide authentication, the basic key derivation mechanism may be 
combined with an authentication technique, e.g., as specified in [IS09798-4]. An 
example for such a combination is given below; 



A 






Rb 

hash( K II Rb II B ) 



-► 



B 



Fig. 10. Key Derivation Mechanism 

1 . B generates a random number and transfers it to A. 

2. Both A and B derive the key K by applying a keyed cryptographic check function 
to the random number Rg, i.e. 

K = hash(K^||Rg). 

3. A returns hash( K || R^ || B ) to B, a cryptographic check value of the established 
secret, the received number Rg and the distinguishing identifier B. 

4. On receipt of this message, B checks that its distinguishing identifier and the 
random number Rg were used in constructing it. 

This mechanism provides mutual Implicit key authentication, authentication of entity 

A and key confirmation for B. 



7 Key Agreement Mechanisms 

Key agreement is the process of establishing a shared secret between two or 
more entities in such a way that no subset of the entities can predetermine the value of 
the shared secret. The most prominent example of a key agreement scheme is the 
Diffie-Hellman protocol [DiHe76]. 

ISO/IEC 11770-3 standardizes seven generic key agreement schemes based on 
asymmetric techniques whose major properties are summarized in table 3 [ISOl 1770- 
3]. In addition, several variants of the Diffie-Hellman protocol and the Menezes-Qu- 
Vanstone key agreement scheme are specified in the current Working Draft of IEEE’s 
Standard for Public Key Cryptography [IEEE1363]. Two point-to-point key 
agreement schemes based on symmetric techniques are defined in ISO/IEC 11770-2 
[ISOl 1770-2]. 
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Table 3. Key Agreement Mechanisms of ISO/IEC 1 1770-3 



7.1 Diffie-Hellman Key Agreement 

The classic Diffie-Hellman key agreement scheme [DiHe76] establishes in two 
passes a shared secret between two entities A and B. The mechanism provides joint 
key control, i.e., neither party can force the shared key to a predetermined value by 
selection of its keying material. However, neither of the entities can be sure about its 
peer’s identity. 



g’' mod p 



g>' mod p 



B 



Fig. 11. Diffie-Hellman Key Agreement 



The Diffie-Hellman protocol is based on the difficulty of the discrete logarithm 
problem^ For the mechanism, A and B need to agree upon an appropriate prime p 
and a generator g of {1, ... , p-1 }. Then the following steps are performed: 

1. A generates a random secret x in {2, ... , p-2}, computes g"‘ mod p and transfers the 
result to B. 

2. B in turn generates a random secret y in {2, ... , p-2), computes mod p and sends 
it to A. 

3. Both A and B then compute the shared value 

K=(g^f = (gf = g^ mod p. 

The above mechanism describes the “traditional” Diffie-Hellman key agreement 
scheme which provides neither key authentication nor key confirmation. 

ElGamal key agreement is a one-pass variant of the Diffie-Hellman protocol where 
one entity uses a static public key agreement key and the other entity needs to have 



The Diffie-Hellman protocol and its variations can be carried out in any group for which the 
discrete logarithm problem is sufficiently hard. Alternatives include the multiplicative group 
of integers mod p and the group of points defined by an elliptic curve over a finite field. The 
mechanisms described here use integers mod p; for examples based on elliptic curves see 
[ISOl 1770-3] or [IEEE1363]. 
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access to an authentic copy of this key. For ElGamal key agreement, the following 
steps are performed; 



A 



mod p 



B 



Fig. 12. ElGamal Key Agreement 

1. A generates a random secret x in {2, ... , p-2}, computes g* mod p and transfers the 
result to B. Furthermore, A computes, using x and B’s public key agreement key 
g , the shared key as 

K = (g")’' mod p. 

2. On receipt of the message, B computes the same shared key using his private key 
agreement key b. 

K = ( gf mod p. 

If static public key agreement keys are distributed using certificates, ElGamal key 
agreement provides unilateral key authentication. Mechanism 2 of ISO/IEC 11770-3 
is a generic version of this scheme (see table 3). 

If both entities use static key agreement keys, key establishment can be performed 
without the need to exchange any messages. For non-interactive Diffie-Hellman key 
agreement, A computes, using her private key agreement key a and B’s public key 
agreement key g , the shared key as 

K = ( gf mod p. 

B computes, using his private key agreement key b and A’s public key agreement key 
g“, the shared key as 

K = ( g“f mod p 

Note, that the value of the shared secret K is completely predetermined. If public key 
agreement keys are distributed using certificates, non-interactive Diffie-Hellman key 
agreement provides mutual key authentication. Mechanism 1 of ISO/IEC 1 1770-3 is a 
generic version of this scheme (see table 3). 

Additional variants of the basic Diffie-Hellman key agreement scheme combine 
the use of static (long-term) key agreement keys with short-term („ephemeral”) 
keying material. This allows to tailor the properties of the scheme to suit the needs of 
a particular application. 

• If one entity provides an authenticated key, the protocol provides unilateral 
implicit key authentication; if both entities do, the implicit key authentication is 
mutual. 

• Similarly, if one entity provides an ephemeral key, a compromise of that entity’s 
static keys will not compromise session keys; if both entities provide ephemeral 
keys, then perfect forward secrecy is achieved. 

Diffie-Hellman key agreement schemes are being standardized by several standards 
groups, including [ISOl 1770-3], [IEEE1363], [ANSIX9.42]. After execution of any 
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variant of the Diffie-Hellman protocol, the entities A and B can use the established 
secret to derive multiple (session) keys using a sequence of common key derivation 
parameters (e.g., counters, time stamps). 



7.2 Station-to-Station Protocol 

The Station-to-Station protocol (STS) [MVV96] is a three-pass variant of the 
basic Diffie-Hellman protocol which provides mutual key and entity authentication. 



A 



g*^ mod p 

^ gy mod p II encK(sigKa,(gy || g^l A)) 

encK(sigKA,(g’^ || || B)) 

► 



B 



Fig. 13. STS Protocol 

1. A generates a random secret x in {2, ... , p-2}, computes g* mod p and transfers the 
result to B. 

2. B in turn generates a random secret y in {2, ... , p-2}, computes mod p and the 
shared key K = (g*)*^. B then signs the concatenation of g^ and g* and the 
distinguished identifier of A and encrypts the signature using the computed key K. 
The result is appended to g^ and transferred to A. 

3. A computes the shared key K = (gO*, deciphers the encrypted data and verifies B’s 
signature. If the verification is successful, A sends B an analogously constructed 
enciphered signature (see figure 13). 

4. B deciphers the received message and verifies A’s signature. 

The STS protocol provides secret key establishment with mutual entity authentication 
and mutual key confirmation. A variant of this mechanism is specified in [ISO11770- 
3] (mechanism 7). Another variant of the STS protocol is being considered for 
standardization with IPsec, the Internet security protocol [Fu97]. 



7.3 Key Agreement Based on Symmetric Techniques 

The following scheme is an example for key agreement based on symmetric 
techniques. The mechanism provides mutual entity and key authentication. 
Uniqueness/timeliness is controlled by random numbers. 
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sncK^( II Rg II B || ^ 

A encK^B(RBllRAllKB) ^ 

Fig. 14. Key Agreement Based on Symmetric Techniques 

1 . B sends A a random number R^. 

2. A in turn sends B a random number R^, the received number R^, the distinguishing 
identifier B, and her keying material K^. The data fields are enciphered with the a 
priori shared key K^. 

3. B deciphers the message, checks the correctness of its distinguishing identifier, and 
that the random number R^ sent to A was used in constructing the message. If all 
checks are successful, B sends A the random numbers R^ and R^, and his keying 
material Kg. The data fields are enciphered with K^. 

4. A deciphers the message and checks that her random number R^ was used in 
constructing it. 

5. Both A and B derive the shared secret K by using a key generating function f with 
inputs the secret keying materials and K^: 

K = f(K„K3). 

The above mechanism is specified in [ISOl 1770-2] (mechanism 6, see also table 1). 

If one of the two keying material fields or Kg is empty, the mechanism becomes a 

key transport mechanism. A two-pass variant of this mechanism (mechanism 5 of 

ISO/lEC 11770-2) makes use of time stamps or sequence numbers instead of random 

numbers. 



8 Key Escrow / Key Recovery 

A key escrow or key recovery scheme is an encryption system with a backup 
decryption capability available under special prescribed conditions. Such a scheme 
allows law enforcement authorities, users, or other authorized persons to decrypt 
ciphertext with the help of key escrow/recovery information supplied by one or more 
TTPs. 

In a general key escrow/recovery scenario one assumes that the communicating 
entities A and B are in different domains (e.g., different countries) and that there is 
the requirement to be able to recover decipherment keys from either domain 
independently. A key escrow/recovery scheme typically includes the following 
mechanisms [DeBr96]: 

• The sending entity prepares for transmission the enciphered message and some 
additional information which enables specific third parties to recover the 
decryption key (should this later become necessary). For this, the sending entity 
may need to involve a TTP. 
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• The recipient checks the correct format of the recovery parameters received with 
an encrypted message and rejects messages where this check fails. 

In a simple example for such a scheme, the sender A takes the session key K used to 
encipher the message M, encrypts this key with the public encryption key of her 
TTP and in addition with the public encryption key of the receiver B’s TTP. The 
enciphered message is then transmitted together with the two encipherments of the 
session key: 

encK,,/K) || encK^g/K) || encK(M). 

With such a protocol, both TTPs independently are able to release the session key K. 

The Royal-Holloway Protocol 

The Royal-Holloway protocol [JMW96] is based on the Diffie-Hellman key 
agreement scheme. The basic idea is to use different keying material for each 
communication direction which is derived from the recipient’s receive key and the 
sender’s send key. Secret receive keys are known to both TTPs involved since they 
are derived from a user’s identity and a secret shared between the TTPs. Send keys 
are unilaterally generated by the sender’s TTP. 




The basic protocol works as shown in figure 15. Let be a prime and g be a 
primitive element modulo p {p and g are public), and let Kt^tb ^ secret key shared 
by T^ and Tg. The protocol then runs as follows: 

1 . A sends a message to her TTP, T^, requesting secure communication with B. 

2. T^ generates a private send key a for A, and transmits to A the values a, g“, a 
signed copy of g“, and g , the public receive key of B (B’s private receive key b 
can be generated by both TTPs from B’s identity and 

3. A computes the session key K = (g'’)“ and transmits g" and the signed copy of g“ to 
B. 

4. B verifies g“ and also computes K = (g”)'’ (assuming that B has already received b 
from Tg). 

As with standard Diffie-Hellman key agreement, the established secret can either be 
used directly, or to transport or derive secret session keys. With the Royal-Holloway 
protocol, the following types of interception are possible: 

• T^ may release A’s private send key a. Then all messages originating from A can 
be deciphered for the lifetime of a. 
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• or Tg may release B’s private receive key b. Then all messages from users in the 
domain of to user B can be deciphered for the lifetime of b. 

• or Tg may release the session key g“'’. Then all messages from A to B can be 
deciphered for the joint lifetime of a and b. 

As can be seen from the types of interception available, while precise targeted 
interception is possible by the third of the three interception types, there is no 
provision for time-bounded interception (except between private send and receive key 
updates). See [AnRo97] for further analysis of the security and efficiency of the 
Royal-Holloway protocol. 



References: 

[AnRo97] 

[ANSIX9.17] 

[ANSIX9.24] 

[ANSIX9.42] 

[ANSIX9.57] 

[DeBr96] 

[DiHe76] 

[FKKD96] 

[Fu97] 

[Hug96] 

[IEEE1363] 

[ISOl 1666-1] 

[ISOl 1666-2] 

[ISOl 1568-1] 



Anderson, R.J.; Roe, M.: „The GCHQ protocol and its problems", 
Proceedings of Eurocrypt'97, Springer LNCS 1233 (1997), 134-148. 
ANSI X9. 17-1985: Financial Institution Key Management 

(Wholesale), 1985. 

ANSI X9. 24-1992: Financial Services Retail Key Management, 
1992. 

ANSI Working Draft X9.42: Public Key Cryptography for the 
Financial Services Industry - Managing of Symmetric Algorithm 
Keys Using Diffie Heilman, 1996. 

ANSI Working Draft X9.57: Public Key Cryptography for the 
Financial Services Industry - Certificate Management, 1995. 
Denning, D.E.; Branstad, D.K.: „A taxonomy for key escrow 
encryption systems". Communications of the ACM, 39(3) (1996), 33- 
40. 

Diffie, W.; Heilman, M.E.: „New Directions in Cryptography", 
IEEE Transactions on Information Theory, 22 (1976), 644-654. 
Ereier, A.O.; Karlton, P.; Kocher, P.C.; Dierks, T.: „The TLS 
Protocol, Version 1.0", Internet-Draft , November 1996. 

Fumy, W. „Internet Security Protocols", this volume, pp. 188-211. 
Hughes, J.: „Combined DES-CBC, HMAC and Replay Prevention 
Security Transform", Internet-Draft, September 1996. 

IEEE P1363: Standard for Public Key Cryptography, Draft March 
1997. 

ISO/IEC 11666-1: Banking - Key Management by Means of 
Asymmetric Algorithms - Part 1: Principles, Procedures and 
Formats, 1994. 

ISO/IEC 11666-2: Banking - Key Management by Means of 
Asymmetric Algorithms - Part 2: Approved Algorithms Using the 
RSA Cryptosystem, 1995. 

ISO/IEC 11568-1: Banking - Key Management (Retail) - Part 1: 
Introduction to Key Management, 1994. 




162 



Walter Fumy 



[ISOl 1568-2] 
[ISOl 1568-3] 
[ISOl 1568-4] 

[ISOl 1770-1] 
[ISOl 1770-2] 
[ISOl 1770-3] 
[1S09798-4] 
[JMW96] 

[MSST97] 

[MVV96] 

[NeSc78] 

[Orm96] 

[RSA78] 



ISO/lEC 1 1568-2: Banking - Key Management (Retail) - Part 2: Key 
Management Techniques for Symmetric Ciphers, 1994. 

ISO/lEC 1 1568-3: Banking - Key Management (Retail) - Part 3: Key 
Life Cycle for Symmetric Ciphers, 1994. 

ISO/lEC Draft International Standard 11568-4: Banking - Key 
Management (Retail) - Part 4: Key Management Techniques Using 
Public Key Cryptography, 1996. 

ISO/lEC 11770-1: Key Management Part 1: Key Management 
Framework, 1991 . 

ISO/lEC 11770-2: Key Management Part 2: Mechanisms Using 
Symmetric Techniques, 1996. 

ISO/lEC Draft International Standard 11770-3: Key Management 
Part 3: : Mechanisms Using Symmetric Techniques, 1996. 

ISO/lEC 9798-4: Entity Authentication - Part 4: Mechanisms using 
cryptographic check functions, 1995. 

Jefferies, N.; Mitchell, C.; Walker, M.: „A proposed architecture for 
trusted third party services", in: Cryptography: Policy and 

Algorithms. Springer LNCS 1029 (1996), 98-104. 

Maughan, D.; Schertler, M.; Schneider, M.; Turner, J.: „lnternet 
Security Association and Key Management Protocol (1SAKMP)“, 
Internet-Draft, Eehruary 1997. 

Menezes, A.J.; van Oorschot, P.C.; Vanstone, S.A.: Handbook of 
Applied Cryptography, CRC Press, Boca Raton, 1996. 

Needham, R.M.; Schroeder, M.D.: „Using Encryption for 

Authentication in Large Networks of Computers", Communications 
of the ACM, 21 (1978), 993-999. 

Orman, H.K.: „The Oakley Key Determination Protocol", Internet- 
Draft, May 1996. 

Rivest, R.L.; Shamir, A.; Adleman, L.: „A Method for Obtaining 
Digital Signatures and Public-Key Cryptosystems", Communications 
oftheACM21 (1978), 120-126. 




Security of Computer Networks 



Jan Verschuren 

TNO-EIB, P.O. Box 5013, 
2600 GA Delft, The Netherlands 
lverschuren@tpd.tno.nl] 



Abstract. A few decades ago, most computers were stand-alone machines: they were able to 
process information using their own resources. Later computer systems were connected to each 
other enabling a computer system to use resources of an other computer as well. 

With the coupling of computer systems, security items emerge: in general the link between 
computers is not protected by thorough physical means. That enables an attacker to tap or 
modify information on the link. 

In this article, a model of a distributed system is given. The provided model can also form a 
basis for security evaluations. Threats to the process of information exchange between 
computer systems are indicated. In order to counter the threats envisaged, so called security 
services can be implemented: two communicating computer systems can use security services 
in order to secure their communication link. In this article, two principal implementations of 
security services are addressed. The qualities of the two implementations of security services 
are compared with each other. 



1 Introduction 

Formerly, computer systems were mainly stand-alone: a computer was able to 
process programs (also referred to as application programs (APs)) using its resources. 
Later computers were coupled by means of a network. The possibility to exchange 
data between computers was considered to be an advantage. The distributed 
configuration offered for example the possibility to store certain data at only one 
location. Besides it became possible to run jobs on other computer systems, if one’s 
own computer was not able to do so. 

In this article we will address security items which are specific for the distributed 
configuration. In order to do so we start with modelling a network of computing 
entities (section 2). In the framework of network security a security policy will be 
needed, stating security requirements which need to be fulfilled by the network. This 
topic is dealt with in section 3. In section 4, attention is paid to the communication 
process. In this way, a background is given for two different implementations of 
security services which aim at a secure information exchange between computers. 
Implications of the use of both implementations are given. Section 5 concludes the 
article. 



B. Preneel, V. Rijmen (Eds.): COSIC'97 Course, LNCS 1528, pp. 163-185, 1998. 
Springer-Verlag Berlin Heidelberg 1998 
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2 Model of a Computer Network 

In the world, there are a lot of entities (human beings, computer systems). These 
can influence each other. 

First we will model the way how human beings can influence each other. A human 
being can notice changes in his environment or - otherwise stated - a human being 
can notice events. In this way he can retrieve information from the environment. Thus 
the human being can get input. A person can also perform actions which can be seen 
as outputs. Both input and output can be modelled by means of bitstreams. 

A human being will act according to a certain way, in other words, a relation will 
exist between input and outputs of a human being or - speaking in terms of our model 
- a relation will exist between bitstreams representing inputs and bitstreams 
representing outputs. This can be represented as follows: at a certain moment person 
A has got a set of inputs Si^ = {ij,^, 12 a’- ini(A)A}- general a human being will be 
able to generate more than one output, so a set of outputs So^ = {o^^, o^^, ..., 0^^^^^^^} 
is possible at a certain moment. Outputs of a person can be varying from sending a 
mail to starting to buy shares. The input-output relation of a human being at a certain 
moment of time t, can be given by a pair consisting of: 

• a set of inputs Si,^ which have been received up to time t. 

• a set of outputs So^ which can be generated at time t. 

During the time a human being may continue to receive inputs. So at moments of 
time, a person A will dispose of different sets of inputs Si,^,, Si^2> SiAm(A)- With 
each of these sets of inputs, a set of outputs So^j, So^^, ..., is defined where 

So^i goes with Si^j, So^^ goes with Si^^ and so on. If the human being has for 
instance received the inputs of Si,^j, then he can provide an output which is one of the 
outputs of So^|. 

The behaviour of a person A can be controlled, if during the life time of the human 
being no other sets of inputs arise than {Si,^|, Si^2> SiAm(A))- 

It is also possible that a person uses a computer system: the outputs available from 
a computer system can serve as input for a human being. On the other side, a person 
can use his outputs as commands for a computer system. A computer system also has 
an input-output relation: the output of a computer system will be dependent on the 
received information. This relation can be given by means of a table which has the 
following form. 
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Table 1: input-output table of a computing entity, describing the input-output 
relationship of a computing entity. 



Input 


Old state 


New state 


Output 


input 1 


state 1 


state 5 


output 1 


input 1 


state 2 


state 1 


output 1 


input 2 


state 2 


state 1 


output 3 



This has to be read as follows. If the computer system is in the old state indicated 
in column 2 (e.g. state 2) and if it receives an input as indicated in the first column 
(e.g. input 2), then it will switch to the new state indicated in the third column (state 
1) and generate the output in the fourth column (output 3). 

Here all possible inputs which an entity can handle are indicated in the input part 
of the table. It is possible that an identical input may lead to different outputs 
dependent on the state of the computing entity. The computer system - acting 
according to his input-output table - can be controlled by limiting inputs to the 
computer system. 

Using the input-output relationships of human beings and also using the tables 
which describe the input-output relation of computing entities, it is possible to follow 
the information flows. More specifically, human beings can start the information flow 
by sending one of their outputs to another entity. By means of the input-output 
relationship of each entity, it is possible to foresee the outputs of each entity 
concerned. Figure 1 gives an illustration. 

In figure 1, the behaviour of each entity is specified: the behaviour of human 
beings is given by indicating pairs of sets of inputs and outputs (each pair consists of 
a set of inputs and a corresponding set of outputs); the behaviour of the computer 
entities is given by a references to tables like Table 1 above. 

In addition to this, the state of the network is given by indicating for each entity its 
present state. The present state for human beings is indicated by giving the received 
set of inputs; the state of a computing entity is given by mentioning the (old) state of 
its input-output table. 

The state of the network is further defined by indicating if the computing entities 
are waiting for input (wfi) or if they are aiming to transmit their output; in other 
words if they are ready for output: rfo. This is also indicated for human beings. 

Figures like figure 1 can be used to find out what information flows may occur and 
what actions (outputs) can be performed by entities. In this way it is possible to find 
out if outputs can be foreseen which are not desired from security point of view. The 
security policy will define if and what outputs are acceptable. This will be further 
dealt with in the next section. 
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{(Si^ j, So^ j), {(Si3 „S 03 j), 




Table I, 
describing 
computer I, 
State 2, 



Table II, 
describing 
computer II 
State 1, 
rfo. 



Fig. 1. Exchange of information between entities 
(human beings and computer systems) 



3 Security Policy 

3.1 Definition 

Initially, the security policy will refer to human beings. ITSEC [1] defines security 
policy as “the set of laws, rules and practices that regulate how assets including 
sensitive information are managed, protected and distributed within a user 
organisation”. Referring to the model of figure 1, the security policy will indicate: 

• which outputs a human being may generate and 

• the conditions when a human being may generate the outputs. 

More information and examples of security policies can be found in [2], [3], [4], [5]. 
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3.2 Verification of a Security Policy 

The security policy states for each human being when he may generate a specific 
output. The human being generates an output dependent on the characteristics of the 
inputs he receives. From this it follows that two items need to be fulfilled for a 
security evaluation: 

1. verification if the behaviour of the human being is as claimed; if we do not know 
when a human being generates certain outputs, then it is difficult to control the 
human being. 

2. If the behaviour of the human being is known, then the human being can be 
controlled by means of limiting the information which is sent to the human being. 
This statement only holds if the human being correctly assesses the received 
inputs. An example can illustrate this. Assume that a human being has the 
intention to treat data of confidentiality class 3 in another way than data of 
confidentiality class 4. Then the human being can only do this correctly if he 
assesses the confidentiality class of the received data correctly. So it is necessary 
from security viewpoint to be sure about the characteristics of the received input 
becoming available to the human being. That is the second item of evaluation: it 
needs to be verified if the characteristics of the inputs which arrive at the human 
being are reliable so that the human being can react correctly on the received 
input. 

Different kinds of inputs can arrive at a human being. In the rest of this article we 
will concentrate on information which is sent from a computer system to the human 
being. From security viewpoint, actually two characteristics can be assigned to that 
information: confidentiality and integrity [6]. 

Confidentiality 

If the received information is characterised as “information of a certain 
confidentiality class” then this means that the information has not been disclosed to a 
defined set of entities. 

Integrity 

If the received information is characterised as “information of a certain integrity 
class”, then this means that the information has not been modified by a defined set of 
entities. 

As we do not concentrate on the mentioned first item of a security evaluation, we 
want to verify if the confidentiality and integrity characteristics of the information 
received by the human being, are correct. 

We will clarify this by means of an example which is illustrated in figure 2. 
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PERSON 

A 



Input 1 1 ^ having 
characteristics C(I, 



Computersystem A 



Output Oj^ with 
characteristics 
C(0,J 



Computer 
system D 



PERSON 

B 



Output O 3 g having 
characteristics 0 ( 0 , g) 



Computersystem B 



Input Ijg with I 
characteristics 
\ C(I,3) 



Computer 
system C 



Network of computer systems 
which process output O, ^ 



L. with characteristics C(L^) 



Fig. 2. Illustration of information exchange between two persons via a network of 

computing entities. 



In figure 2, we illustrated the situation where person A sends information 1^ ^ which 
has characteristics C(Ij^). Ij^ is sent into the network, resulting into an input I^g to 
computer system B. After analysing the received input I^g, computersystem B 
supposes that the characteristics of input I^g are given by CCI^g). In the framework of 
a security evaluation, it is necessary to verify if the confidentiality and integrity 
characteristics of I^g as given in C(l 2 g) are correct. 

Eor a complete security evaluation, it is necessary that these checks are done for all 
possible inputs to computer system B, for all states of the network and for all possible 
outputs from computer system A. 

Several starting points can be chosen. In figure 2, computer system A is the 
starting point and computer system B the end-point. If computer system D would 
have been chosen as starting point and computer system C as end-point, then only a 
qualification of a subnetwork would result. By means of evaluation of several 
subnetworks, it is possible to come to an evaluation of a larger network consisting of 
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the subnetworks. In the rest of this article, we will concentrate on the realisation of a 
secure subnetwork. 



4 Realisation 

Up to now we briefly talked about definition and evaluation of network security. 
Now we want to address realisation aspects. In order to realise a secure network 
despite attackers which tap or modify the information transmitted via the 
communication link between two computer systems, it is necessary to protect the link. 
First we will briefly describe the mechanism of communication between two 
computer systems. Then we will concentrate on adding security measures which can 
prevent or detect attacks on the communication link. 



4.1 Communication Between Computer Systems 

A computer system can be schematically represented by figure 3. 




I/O 



Fig. 3. Schematic representation of a computer system. 



An application program AP is executed by means of the operating system OS 
which is built on a hardware platform. Via an I/O-channel, the Application Program 
can retrieve and transmit information. 

Via I/O channels, the computer system can be connected to a medium. Thus it is 
possible that an AP communicates with an AP on another computer system. The 
medium may be a simple link, it can also be a network to which more computer 
systems are connected. In order to achieve that the information block which is sent by 
an AP (AP^) arrives correctly at the addressee (AP^), additional information has to be 
appended to the information block of the sending AP. In general a separate 
computing entity is used for this purpose. Such a so called communication subsystem 
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appends control information to the information block which is sent by AP^; thus the 
communication subsystem controls the information exchange between two APs on 
two computer systems. This is illustrated in figure 4. 




Fig. 4. AP - AP - communication via a network. 



Several communication subsystems exist. In this article we concentrate on the 
communication subsystem according to the ISO-Reference Model for Open Systems 
Interconnection. 



4.2 The ISO Reference Model for Open Systems Interconnection 

The ISO Reference Model for Open Systems Interconnection consists of 7 layers 
which form together the communication subsystem (fig. 5) , [7]. 
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I 




1 


Data network 






Network environment 






OS I environment 





Real systems environment 



Fig. 5. Overall structure of the ISO-Reference Model 



The layers can be indicated by means of their names or by means of a number N 
(N = 1,2,..., 7). Each layer performs a well defined function in the context of the 
communication between two APs. It operates according to a defined protocol. 
(Protocols are sets of rules that govern the exchange of information between two 
entities.) Performing this protocol results in the exchange of Protocol Data Units 
(PDUs) between two (protocol) entities that belong to the same layer. PDUs which 
are exchanged between two protocol entities of layer N are referred to as N-PDUs. 
These are transported by invoking services provided by the lower layer. More 
specifically, the N-PDU (which is also named (N-l)-SDU: N-1 Service Data Unit) is 
a parameter of a service request which is issued by the N-layer to the (N-l)-layer. 
Subsequently the (N-l)-protocol entity will feel the need to exchange an (N-l)-PDU 
with a peer entity of layer (N-1). The (N-l)-PDU will be equal to the N-PDU 
concatenated with a so called PCI-block (protocol control information block) which 
will contain at least the source and the destination addresses of the service access 
points of the two communicating protocol entities. This PCI-block governs the PDU- 
exchange between the protocol entities as it helps the receiving protocol entity to 
correctly interpret the received PDU. At an (N-l)-service access point ((N-l)-SAP) a 
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protocol entity of layer N can invoke a service provided by a protocol entity of layer 
(N-1). Figures 6 and 7 illustrate the exchange of PDUs between protocol entities. 



Layer N+1 



Layer N 



Layer N-1 




Fig. 6. Interactions between protocol entities in the same system 
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Fig. 7. Interactions between protocol entities in different systems 



The functions of the different layers can be described as follows. 

the physical layer transforms the information to be sent (represented in bits) to 
(physical) signals which can be transported by the transmission medium. 

The link layer provides the network layer with a reliable information transfer 
facility. It is thus responsible for such functions as error detection and, in the 
event of transmission errors, the retransmission of messages. 

The network layer is responsible for the establishment and clearing of a network 
wide connection between two transport layer protocol entities. It includes such 
facilities as network routing (addressing). 

The transport layer provides the session layer with a reliable data transfer facility 
which is independent of the type of network which is being used to transfer the 
data. 
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• The session layer is responsible for establishing and synchronising the dialogue 
between APs. Synchronising a dialogue means that the dialogue can be resumed 
from specific synchronisation points in case of errors. 

• The presentation layer performs the conversion from an abstract syntax (e.g. type 
character) to a concrete syntax (e.g. ASCII) and vice versa. Figure 8 illustrates 
this. 




syntax 



Fig. 8. Function of the presentation layer 



• The application layer enables APs to get access to a range of network wide 
distributed information services. For instance an AP can get access to a remote 
file server AP which enables the requesting AP to get access to files managed by 
the file server AP. 

As mentioned before, an N-protocol entity has to transmit PDUs (N-SDUs) - 
which it gets as a parameter in a service request - to a peer protocol entity. Two 
possible ways exist to do this. 

1 . The entity first establishes a connection with the peer entity. If this is settled, then 
the N-SDU in question is transmitted via the connection. This is referred to as a 
“connection oriented” service. 
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2. The N-SDU is transmitted without first establishing a connection. This is denoted 
by the term “connectionless” service. 

Out of the foregoing it turned out that the network layer is responsible for routing 
PDUs between computer systems. A schematic representation of a computer system is 
given in figure 9. 



Terminals 




Fig. 9. Computernetwork 



The nodes must be able to transmit an arriving PDU in the right direction. 
Therefore a node must be equipped with protocol entities belonging to the lower three 
layers of the OSI-RM. Figure 10 gives a schematic illustration of a node and the 
function it performs. 
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node 




Fig. 10. Routing function of a node 



The total address of an AP does not only consist of the physical network-wide 
address of the computer system it is running on. It is built up out of SAPs in the 
following way. 

APaddress = PSAP H- TSAP H- NSAP 

Here PSAP, TSAP and NSAP denote the addresses of the service access points 
between the application layer protocol entity to which the AP is connected and the 
presentation layer, between the session layer and the transport layer and between the 
transport and the network layer. The NSAP also contains the physical network wide 
address of the system in which the AP is resident. 



4.3 Threats 

The fact that information transferred between two computers is transported via a 
public medium (e.g. a telephone network), makes it extra vulnerable in comparison 
with information exchanged between APs both running on the same stand-alone 
system. More specifically, data in stand-alone systems is not easily available whereas 
data transported via public networks is: in general public media are not protected by a 
physical barrier. Therefore everyone can easily tap information or even modify it. 
Thus two forms of attacks can be discerned. 

• passive attacks resulting in unauthorised disclosure of information. 

• active attacks resulting in modification of the transmitted information. 
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From section 4.2 it turned out that the information which is transferred via the data 
communication network is twofold: 

• user data 

• data governing the communication between two entities (protocol control 
information) 

So passive attacks can result in the disclosure of user data or of information 
concerning the communication (e.g. the addresses of the sending and receiving 
computersy s tem) . 

Active attacks intend to modify user data or PCI-blocks. Changing the address of 
the sending computersystem is an example of modifying the PCI-block. That will 
make the receiver think that the data came from another system. 

The threats just mentioned refer to the situation where two APs are already 
communicating. Prior to this phase, the communication must be started: an AP 
attempts to set up a connection with another AP. Then it must be decided if the two 
APs are allowed to communicate with each other. More specifically, it must be 
prevented that an AP uses resources (e.g. data belonging to another AP) in an 
unauthorised way. 

After the data has been transmitted from sender to receiver, other threats are 
present: 

• the receiver states it did not get the data 

• the sender states it did not send the data 

So the threats to be envisaged, can be summarised as follows: 

• unauthorised access to resources 

• disclosure or modification of transmitted data 

• false statements of entities which sent or received data 



4.4 Realisation of Security Services 

Protection needs to be supplied to prevent the threats as mentioned in section 4.3 to 
work out successfully. This protection can be realised by means of security services. 

While addressing the realisation of security services, we can discern two principal 
locations where security services can be realised. 

1 . In the communication subsystem 

By means of a communication subsystem an AP can exchange 
information with another AP. So the communication subsystem supports an 
AP: it can provide an AP with the functionality of a communication link. 
Implementing security services into the communication subsystem, leads to a 




178 



Jan Verschuren 



situation where the communication subsystem can provide the AP with a 
secure communication link. The option where security services are 
implemented in a communication subsystem according to the OSI-RM is 
addressed in section 4.4.1. 

2. At the level of the Application Program 

The communication subsystem provides the AP with a communication 
link; initially, the communication subsystem does not provide a secure 
communication link. Incorporating security services in the AP itself, leads to 
a situation where the AP itself builds a secure link on the offered insecure 
communication link. This option is further dealt with in section 4.4.2. 



Security Services in the OSI-RM In section 4.3, the threats to user data and to the 
protocol control information were mentioned. Looking at figure 7, it can be derived 
what information can be protected at what layer. It follows that at the level of the AP 
only user data can be protected. Security services within the protocol entities of the 
OSI-RM can protect protocol control information as well. The security services - 
integrated in the protocol entities - can have different forms. That is mainly dependent 
on the way the communication is set up between two entities. (More specifically, that 
can be done by means of a connectionless or a connection-oriented service.) 

Now the definition of the security services (with respect to the OSI-environment) 
will be given [8]. 

• Authentication. 

This service can take two forms: peer entity authentication and data origin 
authentication. The first one refers to a connection-oriented mode of 
transmitting PDUs, the second one assumes a connectionless mode. 

Peer entity authentication 

This service is provided at the establishment of, or at times during the 
data transfer phase of, a connection to confirm the identities of one or more 
of the entities connected. This service provides confidence that an entity is 
not attempting a masquerade or an unauthorised replay of a previous 
connection. 

Data origin authentication 

The service, when provided by the (N)-layer, provides corroboration to 
the (N-Hl)-layer that the source of the data is the claimed (N-Hl)-peer entity. 
The data origin authentication service is the corroboration of the source of a 
single connectionless data unit. The service cannot protect against 
duplication of a data unit. 
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Access Control 

This service provides protection against unauthorised use of resources 
accessible via OSI. These may be OSI or non-OSI resources accessed via 
OSl-protocols. This protection service may be applied to various types of 
access to a resource (e.g. the use of a communications resource; the reading, 
writing or the deletion of an information resource; the execution of a 
processing resource) or to all accesses to a resource. 

Data confidentiality. 

The following forms of this service are defined. 

Connection confidentiality 

This service provides for the confidentiality of all (N)-user-data on an 
(N)-connection. 

Connectionless confidentiality 

This service provides for the confidentiality of all (N)-user-data in a 
single connectionless (N)-SDU 

Selective field confidentiality 

This service provides for the confidentiality of selected fields within the 
(N)-user-data on an (N)-connection or in a single connectionless (N)-SDU. 



Traffic flow confidentiality 

This service provides for the protection of the information which might be 
derived from observation of traffic flows. 

Data integrity 

The following forms of this service are defined. 

Connection integrity with recovery 

This service provides for the integrity of all (N)-user-data on an (N)- 
connection and detects any modification, insertion, deletion or replay of any 
data within an entire SDU sequence (with recovery attempted; i.e. after 
detecting that the integrity of the user data is not fulfilled, subsequent 
attempts are carried out to get the user data of which the integrity is 
preserved). 

Connection integrity without recovery 

The same as the previous one but with no recovery attempted. 

Selective field connection integrity 

This service provides for the integrity of selected fields within the (N)- 
user data of an (N)-SDU transferred over a connection and takes the form of 
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determination of whether the selected fields have been modified, inserted, 
deleted or replayed. 

Connectionless integrity 

This service provides for the integrity of a single connectionless SDU and 
may take the form of determination of whether a received SDU has been 
modified. Additionally, a limited form of detection of insertion or replay 
may be provided. 

Selective field connectionless integrity 

This service provides for the integrity of selected fields within a single 
connectionless SDU and takes the form of determination of whether the 
selected fields have been modified. 

• Non-repudiation 

This security service can take two forms 

Proof of origin 

The recipient of data is provided with proof of the origin of data which 
will protect against any attempt by the sender to falsely deny having sent the 
data. 

Proof of receipt 

The sender of data is provided with proof of receipt of data which will 
protect against any attempt by the recipient to falsely deny having received 
the data or its contents. 

Part 2 of ISO-standard 7498 [8] gives guidelines at which layer(s) the security 
services can be provided (figure 11). 

Making a choice out of the possibilities denoted by fig. 11, depends on the security 
policy of the two APs. As is seen in chapter 3, a security policy specifies how 
sensitive information has to be protected. Each AP tries to follow a certain security 
policy when communicating with another AP. If both policies do not agree initially, 
then negotiation is necessary. If this is successful, then the agreed security policy will 
result in a set of invoked security services which will be applicable to the 
communication. More specifically, not all security services available, will be used for 
each information exchange. Consider for example the following situation: an AP 
wants to extract address-information out of a file system on a remote end-system. In 
that case the requesting AP is concerned about the integrity of the received address, 
not about its confidentiality. So the integrity service needs to be applied whereas the 
confidentiality service is not necessary. 

So, dependent on the agreed security policy a set of security services needs to be 
invoked. 

For realising the security services, so called security mechanisms have to be 
applied. E. g. the confidentiality service can be realised by the encipherment 
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Fig. 11. Illustration of the relationship of security services and layers 



mechanism. Figure 12 gives the relationship between services and mechanisms. The 
description of all mechanisms is given in [8]. To prevent misunderstanding of the 
table given in figure 12, the following remark may be helpful. Although 
encipherment forms only one column of the table, cryptographic techniques may be 
employed as part of other mechanisms such as digital signature, data-integrity, 
authentication. An example of a security mechanism which needs not to use 
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Fig. 12. Relationship of security services and mechanisms 

cryptographic techniques is routing. The routing mechanism causes information to be 
transmitted via a special communication path, e.g. via one or more secure 
subnetworks. 
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To give an idea of the effect of placing a security service at different layers 
examples with respect to three security services will be given. 

Confidentiality 

Encipherment at two different layers is considered. 

• application layer 

• physical layer 

As was described in section 4.2, the nodes of the network are equipped with 
protocol entities belonging to the three lower layers of the OSTRM. This implies that 
encipherment of the information at the application layer does not cause problems: the 
nodes can read and interpret the address information in the PCTblock added by the 
network-layer as this is not enciphered. (The same counts for encipherment at the 
level of the transport-layer.) Encipherment applied at the transport or application 
layer is referred to as end-to-end-encryption as during transport no deciphering of the 
PDUs takes place; they are deciphered for the first time when they arrive at their 
destination. Encipherment at the physical-layer necessitates decipherment of the PDU 
at the nodes to enable the node to determine the direction in which it has to send the 
PDU. This implies that at the node the whole PDU (including the user data sent by the 
AP) is in the clear. This may be unacceptable for the communicating APs. 
Encipherment at the physical layer has an advantage however. It will imply that an 
enemy who taps the line will see nothing of the structure of the information. He will 
therefore be unaware of the sources and destinations of messages and may even be 
unaware whether messages are passing at all. This provides ‘traffic-flow 
confidentiality’ which means that not only the information, but also the knowledge of 
where the information is flowing and how much is flowing is concealed from the 
enemy. By implementing encipherment at the lowest level, traffic-flow confidentiality 
can be obtained. 



Access Control and Authentication 

In section 4.2 the address structure was seen. APaddress = PSAP + TSAP + NSAP. 
As a result of this, it can be said that the access control service at the A-layer can 
deny or approve access to a specific AP as at that level the AP is fully specified. At 
the N-layer (or T-layer) however, only access can be given or denied to a group of 
APs. Analogously, the data-origin and peer-entity authentication services realised in 
the N-layer or T-layer can only assure that the data origin respectively peer-entity is a 
member of a group of entities. Realisation of the mentioned security services in the 
A-layer gives assurance with respect to a specific entity. 



Security Services Realised at the Level of the Application Program When 
security services are implemented at the level of the Application Program (AP), then 
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it follows from figure 7, that no Protocol Control Information (PCI) can be protected. 
Only the confidentiality and integrity of the information block which is sent by the 
AP can be protected. So a realisation of security services in the communication 
subsystem can lead to a richer security functionality than a realisation of security 
services at the level of the AP. 

Realising the security services at the level of the AP implies that the receiving AP 
must be able to interpret the secured messages from the sending AP. In other words, 
standardising at the level of APs has to take place. This means that at two locations 
standardisation has to take place: at the level of APs and at the level of 
communication subsystems. 



5 Conclusions 

Network security concentrates on protecting the link between two computing 
entities. More specifically, information which is sent from one computer system to 
another computer system needs to be protected. 

Use of so called security services can lead to a secure link. In order to realise 
network security, two principal implementations can be discerned: 

• Implementation of security services in a communication subsystem (e.g. OSI- 
RM). 

• Implementation of security services at AP-level. 

Comparing these two possibilities, we can say that realising security services in a 
communication subsystem, can lead to a more extensive security level. 

Realising security services at the level of an AP, leads to a less open environment: 
APs can only communicate securely with each other if the security services adopted 
by both APs match with each other. Realisation of security services in an OSI 
communication subsystem can lead to an open environment which still can be secure. 
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Abstract. This article describes various efforts to address security in three areas 
of the Internet protocol suite: the Internet Protocol itself (IPsec), the domain 
between transport and application layer (the Secure Sockets Layer and the 
Transport Layer Security protocols) and security extensions for the HyperText 
Transfer Protocol (S-HTTP). For each area the current technology, relevant 
standardization activities and likely future developments are discussed. In 
addition, a brief introduction to the Internet standardization process is given. 



1 Motivation 

Any network connected to the Internet is at risk of intrusion. In 1995, Carnegie 
Mellon University's CERT (Computer Emergency Response Team) responded to 
more than 2,400 legitimate security breaches in the United States involving more than 
12,000 Internet sites. The most common methods of deliberate intrusion identified by 
CERT are 

• IP spoofing, whereby an intruder masquerades as a node whose Internet Protocol 
address is known and trusted, and 

• packet sniffing, which invaders use to extract valid account names and passwords 
or credit card information from captured, unenciphered IP datagrams. 

Part of the reason for the Internet security risks is the lack of effective security 
mechanisms in the current version of the Internet Protocol (IPv4). Other reasons are 
lax security practices in many network environments and some network 
administrators' lack of knowledge about Internet and Intranet security. 

On the other hand, the ease of use of the World Wide Web has prompted 
widespread interest in its employment as a client/server architecture for many 
applications. As increasing amounts of sensitive information, such as credit card 
numbers, are being transmitted over the Internet, security issues have become of 
central importance. 

Most companies with connections to the Internet have implemented firewall 
solutions to protect their corporate network from unauthorized users coming in and 

B. Preneel, V. Rijmen (Eds.): COSIC'97 Course, LNCS 1528, pp. 186-208, 1998. 
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unauthorized Internet sessions going out. However, while firewalls can guard against 
intrusion and unauthorized use, they can guarantee neither the security of the 
connection between a particular workstation and a particular server on opposite sides 
of a firewall nor the security of the actual messages being conveyed. To create this 
level of security, Internet security protocols, such as the IP Encapsulating Security 
Payload (ESP), the Secure Sockets Layer (SSL) protocol, or the Secure HyperText 
Transfer Protocol (S-HTTP), ensure that sensitive information traveling through the 
Internet is safe from eavesdropping. 

The primary goal of all network security protocols is to provide confidentiality, 
data integrity and authentication between communicating parties. The capabilities of a 
security protocol depend not only on its design but also on its location in the protocol 
stack. 

This article describes various efforts to address security in three areas of the 
Internet protocol suite: the Internet Protocol itself (IPsec), the domain between 
transport and application layer (SSL and TLS, the Transport Layer Security protocol), 
and security extensions for the HyperText Transfer Protocol (S-HTTP). Lor each area 
the current technology, relevant standardization activities and likely future 
developments are discussed. 

The paper shows that the technology for secure Internet communications is largely 
available. However, progress in this area is also influenced by several non-technical 
issues. E.g., the desire to avoid patented technologies, the mistrust of some specific 
techniques (e.g., key escrow, key recovery), and the existence of export controls and 
other regulations can hinder or delay the deployment of technologies based on 
cryptographic techniques. 



2 The Internet Protocol Suite 

Network protocols are typically developed in layers, with each layer responsible 
for a different aspect of the communication. Each layer has protocols for 
communicating with its peer at the same layer. The Internet protocol suite is 
considered to be a four-layer system, as shown in figure 1 . 
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Fig. 1: Internet Protocols 



The lowest layer is the link layer which provides the physical interfacing with the 
communications medium (e.g., the Ethernet cable). The network layer handles the 
movement of packets around the network. The transport layer provides a data flow 
between two hosts, for the application layer above. The application layer finally 
handles the details of the particular application. 

IP, the Internet Protocol is the basis for the global Internet. Both IP version 4 
(IPv4) and the next generation IF0 (IPv6, [RFC 1883]) provide unreliable data 
transmission between nodes. The network layer of the Internet includes not only IP, 
but also the Internet Control Message Protocol (ICMP) and the Internet Group 
Membership Protocol (IGMP). In the Internet protocol suite there are two different 
transport protocols. Most Internet applications use the Transmission Control Protocol 
(TCP) layered above IP which provides transmission reliability. Multicast 
applications and applications that do not need reliable transport use the much simpler 
User Datagram Protocol (UDP) instead. 

Common applications provided by almost every TCP/IP implementation are telnet 
for remote login, the File Transfer Protocol ftp and SMTP, the Simple Mail Transfer 
Protocol. The World Wide Web (WWW) is a distributed hypermedia system which 
has gained widespread acceptance among Internet users. The native and primary 
protocol used between WWW clients and servers is the HyperText Transfer Protocol 
(HTTP). 



3 Internet Standards 

The Internet Engineering Task Force (IETF) is the technical group responsible for 
engineering and evolving the Internet, and the principal body engaged in the 
development of Internet specifications. Most of the technical work takes place in 
working groups. Currently active IETF working groups in the security area are: 



* Even after IPv6 is deployed, IP version 4 is likely to remain used for a long time. 
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• An Open Specification for Pretty Good Privacy (OPENPGP) 

• Authenticated Firewall Traversal (AFT) 

• Common Authentication Technology (CAT) 

• Domain Name System Security (DNSSEC) 

• IP Security Protocol (IPSEC) 

• One Time Password Authentication (OTP) 

• Public-Key Infrastructure (X.509) (PKIX) 

• S/MIME Mail Security (SMIME) 

• Secure Shell (SECSH) 

• Simple Public Key Infrastructure (SPKI) 

• Transport Layer Security (TLS) 

• Web Transaction Security (WTS) 

Specifications for Internet security protocols are developed in three of those 
working groups: IPSEC, TLS, and WTS. 

Documents called Request for Comments (RFCs) are the official documents of the 
Internet Architecture Board (lAB) which maintains the standards for the Internet 
protocol suite. Internet documents less mature or less stable than RFCs are typically 
available as Internet-Drafts. Internet-Drafts have no formal status, are valid for a 
maximum of six months, and can be changed or deleted at any time. 

The RFC series comprises a wide range of documents, ranging from informational 
documents of general interest to specifications of protocols ("all Internet standards 
are published as RFCs, but not all RFCs specify standards"). Once a document is 
assigned an RFC number and published, it is never revised or re-issued with the same 
number. Therefore, the question is not having the most recent version of a particular 
RFC but having the most recent RFC on a particular protocol. RFCs are available 
from several Web-sites (e.g., http://ds.internic.net/ds/rfc-index.html). 

There are two independent categorizations of RFCs. The first is the maturity level 
or state of standardization. Protocols which are to become Internet standards go 
through a series of states {Proposed Standard, Draft Standard, and Standard) 
involving increasing amounts of scrutiny and testing. At each step, the Internet 
Engineering Steering Group (lESC) must make a recommendation for the 
advancement of the protocol. Possible states of a RFC are: 

• Proposed Standard (PS): Advancement from Internet-Draft to Proposed Standard 
puts a protocol "on the standards track", i.e., these are protocol proposals that may 
be considered by the lESG for standardization in the future. Implementation and 
testing by several groups is desirable. 

• Draft Standard (DS): The lESG is actively considering such protocols as possible 
standards. It is general practice that no Proposed Standard can be promoted to 
Draft Standard without at least two independent implementations. 
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• Standard (STD): Promotion from Draft Standard to Standard generally requires 
operational experience and demonstrated interoperability of two ore more 
implementations . 

• Historic (H): These are protocols that have been superseded by later developments 
or have become obsolete due to lack of interest. 

• Experimental (E): Typically protocols developed as part of an ongoing research 
project and not related to an operational service offering. 

• Informational (I): Other documents, such as protocols developed hy other 
standard organizations, or hy particular vendors, which are published as RFCs for 
the convenience of the Internet community. 

The second categorization is the requirement level or status of a protocol, varying 
from Required (i.e., a system must implement it). Recommended (i.e., a system should 
implement it). Elective, Limited Use, to Not Recommended. Only protocols on the 
standards track (i.e., PS, DS, and STD protocols) are labeled with a status. 



4 Security for the Internet Protocol 

Cryptographic security mechanisms are not widely available on the Internet layer. 
In the 1980s, the Secure Data Network System (SDNS) project has developed a 
network security architecture including security protocols for the network and the 
transport layer [RFC1108]. SP3, the SDNS network security protocol, was designed 
as a sublayer residing directly helow the transport layer. It offered the security 
services of confidentiality, data integrity and data origin authentication. The basic 
concepts of the ISO/IEC Network Layer Security Protocol (NLSP) [IS011577] 
designed for the OSI network layer are largely derived from SP3. Due to the lack of 
commercial interest in the Internet at that time, the use of SP3 has been very limited. 

During the past years, the IP Security Protocol (IPSEC) working group of the 
lETE has made progress in adding cryptographic security techniques to standards for 
the Internet infrastructure. The security architecture specified for IP provides 
cryptographic security services that support combinations of authentication, integrity, 
access control, and confidentiality. 
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Fig. 2: IP Security Protocol 



The IP Security Architecture [RFC1825], [KA98aJd describes security 
mechanisms for IP version 4 (IPv4) and IP version 6 (IPv6). It defines two specific 
security headers. The first is the Authentication Header which provides integrity and 
authentication [RFC 1826], [KA98b]. The second is the Encapsulating Security 
Payload (ESP) which provides confidentiality, and (depending on algorithms and 
modes) may also provide integrity and authentication [RFC 1827], [KA98c]. 

The two IP security mechanisms can be used independently of one another, in 
combination with one another, or in an iterated (nested) fashion. They are defined 
algorithm-independent so that the cryptographic algorithms can be replaced without 
affecting the other parts of an implementation. Standard default algorithms are 
specified to ensure interoperability. 

Both IP security mechanisms can provide security services between a pair of 
communicating hosts, between a pair of communicating security gateways, or 
between a security gateway and a host. Depending on a suitable key management, 
AH and ESP also are able to support multicast communications. 

Support for key management methods where the keying material is carried in-line 
within the IP layer was not a design objective. Instead AH and ESP are intended to 
primarily use key management methods where the keying material will be carried by 
an upper layer protocol, or will be distributed manually. 

Protocols and cryptographic techniques to support the key management 
requirements of the IP layer security are under development. The Internet Key 
Management Protocol (IKMP) is specified as an application layer protocol that is 



^ [KA98a], [KA98b] and [KA98b] are revised versions of the Proposed Standards [RFC1825], 
[RFC 1826] and [RFC 1827]. It is intended that future versions of these documents be 
submitted to the lESG for publication as Draft Standard RFCs. 
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independent of lower layer security protocols. IKMP is based on the ISAKMP/Oakley 
work [MSST97], [Orm96]. The Oakley key establishment protocol is a variant of the 
well-known Diffie-Hellman key exchange which provides perfect forward secrecy 
[Fum98]. 

Many of the basic concepts of the IP Security Architecture are derived from or 
were influenced by the SDNS security protocol specifications [SDNS], the NLSP 
specification [IS011577], and from the SNMPv2 Security Protocol [RFC1446]. 



4.1 The IP Authentication Header 

The IP Authentication Header (AH) [RFC 1826], [KA98b] is designed to provide 
data integrity and data origin authentication to both IPv4 and IPv6 datagrams. In 
addition, it may provide non-repudiation, depending on which cryptographic 
algorithms are used and how key management is performed. The lack of a 
confidentiality mechanism is to ensure that AH implementations can be widely 
deployed, also in locations where the export, import, or use of encryption to provide 
confidentiality is regulated. 

The IP Authentication Header adds authentication information (typically a 
Message Authentication Code) to an IP datagram. The authentication information is 
calculated using a secret authentication key and the fields in the IP datagram which 
do not change during transmission (including the IP Header, other headers and the 
user data). Fields or options which need to change in transit (e.g., "hop count", or 
"time to live") are zeroed for the calculation. The default length of the authentication 
information is 96 bits. 

If a symmetric authentication algorithm is used and intermediate authentication is 
desired, then the nodes performing such intermediate authentication are able to forge 
or modify traffic. In the case of public-key techniques, intermediate nodes could 
authenticate the traffic without being able to forge or modify messages. 

All IPv6-capable nodes and all IPv4 systems claiming to implement the 
Authentication Header must implement mandatory message authentication 
techniques. As of this writing these are HMAC-MD5 [MG98a] and HMAC-SHA 
[MG98b] (see below). Other algorithms may additionally be supported. 

The revised specification of AH [KA98b] differs from RFC 1826 in several 
respects. The default algorithms required for interoperability have been changed from 
keyed MD5 (as specified in RFC 1828) to HMAC based on MD5 or SHA-1. 
Furthermore, an anti-replay service is now an integral part of AH and carriage of a 
32-bit field that contains a monotonically increasing counter value (sequence number) 
to support this service is mandatory. The sequence number is used to guarantee that 
each packet exchanged between two parties is different. An authentication key must 
not be active for a period of time that allows the counter to wrap, that is, for more 
than 2 packets. 
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IP Authentication Using Keyed MD5 

A common suggestion for the calculation of authentication information is to 
construct a Message Authentication Code (MAC) from a hash-function by including a 
secret key as part of the hash-function input. RFC 1828 specifies how to use keyed 
MD5 for the Authentication Header. The shared authentication key is involved in 
both the start and the end of the MAC computation, a technique known as envelope 
method with padding. 

MD5 hashes its input by iterating a basic compression function that operates on 
5 12-bit blocks of data. To compute the keyed MAC, 

MD5( K II pad || data || K ) 

the key K is filled to the next 512-bit boundary, using the padding technique 
defined for MD5 [RFC1321]. The result is concatenated with the relevant fields of the 
IP datagram, and with the authentication key again. A trailing padding for the entire 
message to the next 512-bit boundary is added by MD5. The 128-bit hash-value is 
calculated as described in RFC 1321 and used as authentication information. 

However, it has been shown that such one-key envelope methods are vulnerable to 
key recovery attacks [PV96]. Therefore, alternative techniques for the IP 
Authentication Header have been developed. 

HMAC 

RFC 2104 is an informational document that specifies an alternative keyed MAC 
transform called HMAC using a generic cryptographic hash-function. Candidate 
hash-functions for HMAC include MD5, SHA-1 [FIPS180-1], RIPEMD-128, and 
RIPEMD-160 [DBP96], [KP98]. 

HMAC is based on a hash-function which operates on blocks of B bytes of data. 
Let L denote the byte-length of the hash-value (e.g., L=16 for MD5 and RIPEMD- 
128, L=20 for SHA-1 and RIPEMD-160). The authentication key K can be of any 
length, the minimal recommended length for K is L bytes. Applications that use keys 
longer than B first need to hash the key and then use the result as the actual key to 
HMAC. K is appended with zeros to create a B byte string. Eurthermore, two fixed 
strings ipad (0x36 repeated B times) and opad (0x5C repeated B times) are defined. 
HMAC then is 

hash( K opad || hash( K ipad || data )) 

Despite two hash-function calls, the HMAC construction is quite efficient, since 
the outer hash-function only processes a two-block input, independent of the length of 
the data. 

[MG98a] specifies a keyed MD5 transform based on HMAC for use with either 
ESP or AH. To compute HMAC-MD5, the authentication key K is appended with 
zeros to create a 64 byte string. The mandatory key-length is 128 bits. HMAC-MD5 
then is 
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MD5( K opad || MD5( K ipad, data )). 

MD5 generates a message digest of 128 bits. As described in RFC 2104, this 128- 
bit value can be truncated. For use with either ESP or AH, [MG98a] specifies to use 
the truncated value consisting of the first 96 bits. 

[MG98b] specifies a similar transform using SHA-1: 

SHA( K opad || SHA( K ipad, data )). 

SHA-1 generates a message digest of 160 bits which makes it more resistant to 
brute force attacks than MD5. Again, for application with either ESP or AH, 
[MG98b] specifies to only use the first 96 bits. The mandatory key-length for this 
HMAC transform is 160 bits. 



4.2 The IP Encapsulating Security Payload 

The IP Encapsulating Security Payload (ESP) [RPC 1827], [KA98c] is designed to 
provide data confidentiality, data origin authentication, connectionless integrity, an 
anti-replay service, and limited traffic flow confidentiality for IP datagrams. 
Confidentiality may be selected independent of all other services and is always 
provided if ESP is present. Data origin authentication and connectionless integrity are 
joint services offered as an option in conjunction with confidentiality. As with AH, 
these services are provided by adding authentication information. The anti-replay 
service may only be selected if data origin authentication is selected. Alternatively, 
the IP Authentication Header may be used in conjunction with ESP to support data 
origin authentication, connectionless integrity, and replay detection. 

Unlike AH, ESP offers security only for the protocols encapsulated by it, not for 
the protocol that carries it. The most obvious use of ESP is to provide security 
services for upper layer protocols such as TCP or UDP, without protection to the IP 
header that carries these protocols (this ESP use is referred to as Transport mode). 
Alternatively, ESP may encapsulate an entire IP datagram (Tunnel mode). Because 
ESP is an encapsulation protocol, it may be employed recursively, to create nested 
security associations. 

Tunnel mode typically is used by security gateways for packets not originating on 
the gateway. It can be used to create virtual private networks across untrusted 
backbones via security gateways implementing ESP (gateway-to-gateway 
encryption). When two hosts directly implement ESP and there is no intervening 
security gateway (host-to-host encryption), they probably will use the Transport 
mode. This mode reduces both the bandwidth consumed and the protocol processing 
costs for users that don't need to keep the entire IP datagrams confidential. 

The ESP format is designed to support a variety of encryption and authentication 
algorithms. If an algorithm is employed that requires the payload to be a multiple of 
some number of bytes (e.g., the block size of a block cipher), a padding field of up to 
255 bytes is used. Padding may also be required for other alignment reasons or may 
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be used to conceal the actual length of the payload. If padding is needed and not 
specified hy the algorithm, a default process is used where the padding bytes are 
filled with a sequence of monotonically increasing 1-byte integer values, starting with 
1 . 



For interoperability, all conforming implementations of ESP must implement a 
number of mandatory ESP algorithms. As of this writing, these are DES in CBC 
mode [MD98] (see helow), HMAC-MD5 [MG98a] and HMAC-SHA-1 [MG98b]. 
Other algorithms may additionally be supported. 

The revised specification of ESP [KA98c] differs from RFC 1827 in several 
significant ways. RFC 1827 provides a framework that is completed through the 
definition of transforms that may be offered in the context of ESP. The comhinatorial 
growth of proposed transforms motivated the reformulation of the ESP as a more 
complete specification. Eields previously defined in transform documents are now 
part of the base ESP specification. E.g., the fields necessary to support data origin 
authentication and anti-replay are defined in [KA98c], even though the provision of 
these services is an option. 

DES-CBC Transforms 

RFC 1829 describes the ESP use of the Cipher Block Chaining (CBC) mode 
[ISO10116] of the Data Encryption Standard (DES) [FIPS46-1]. The transform 
provides data confidentiality only. 

The keying material necessary for this transform consists of the secret 56-bit DES 
key shared between the communicating parties and a 64-bit Initialization Vector (IV) 
required for the CBC mode. The IV value should not repeat during the lifetime of the 
DES key. Therefore, the session key should be changed at least after 2^^ enciphered 
datagrams. 

DES is a block cipher that operates on 64-bit blocks. This typically requires 
padding after the end of the unencrypted payload data. For encryption, the plaintext is 
padded with zeroes to make its byte-length equal to 6 modulo 8. Then, a byte 
containing the number of padding octets and a byte identifying the protocol header is 
appended. The payload is encrypted with DES in CBC mode, producing a ciphertext 
of the same length. 

RFC 1851 is an experimental RFC that specifies a variant of the DES-CBC 
transform which uses Triple-DES (3DES-EDE) instead of DES. In this case, the 
shared key is 168 bits long and consists of three independent 56-bit quantities. 

[MD98] is a revised version of RFC 1829 that requires an explicit 64-bit 
Initialization Vector. This IV immediately precedes the encrypted payload and must 
be a random value. Including the IV in each datagram ensures that decryption of each 
received datagram can be performed, even when some datagrams are dropped, or 
datagrams are re-ordered in transit. Unlike RFC 1829, [MD98] does not specify a 
padding technique, i.e., for padding the default process specified in [KA98c] is used. 
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4.3 Combining AH and ESP 

A node normally will not apply both AH and ESP to the same IP datagram. The 
datagrams transmitted over an individual Security Association (SA) are protected by 
exactly one security protocol, either AH or ESP. If confidentiality is a requirement, 
then the ESP header needs to be used, otherwise the Authentication Header should be 
used. 

Sometimes a security policy may call for a combination of security services for a 
particular traffic flow that is not achievable with a single SA. In such instances it will 
be necessary to employ multiple SAs to implement the required security policy. SAs 
may be combined in two ways - transport adjacency and iterated tunneling. These two 
approaches can also he combined. 

Transport adjacency refers to applying more than one security protocol to the same 
IP datagram without invoking tunneling. This approach to combining AH and ESP 
allows for only one level of combination, since further nesting yields no added 
benefits. The Authentication Header is placed before the ESP header and is calculated 
across the entire IP datagram, i.e., AH is applied to the ciphertext output of ESP. 

Iterated tunneling refers to applying multiple layers of security protocols effected 
through IP tunneling. This approach allows for multiple levels of flexible nesting, 
since each tunnel can originate or terminate at different sites along the path. 



5 Transport Layer Security Protocols 

A variety of specific protocols has been proposed for adding security services to 
TCP. An important advantage of transport layer security protocols is that they are 
application protocol independent and that higher level protocols can transparently 
layer on top of them. Prominent examples for transport layer security are Netscape’s 
Secure Sockets Layer (SSL) protocol, Microsoft’s Private Communication 
Technology (PCT) and the Transport Layer Security (TLS) protocol currently being 
standardized by the IETF. 



5.1 SSL 

The Secure Sockets Layer (SSL) protocol was developed by Netscape 
Communications. SSL operates above the transport layer and is application 
independent. The protocol provides authentication, data compression, data integrity, 
and data encipherment. It supports various authentication and encryption techniques 
and can protect any application-layer protocol such as the HyperText Transfer 
Protocol (HTTP), ftp, telnet, or the Simple Mail Transport Protocol (SMTP). 
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Netscape’s Navigator and Microsoft's Internet Explorer both support SSL at the 
browser level, and Netscape's Commerce Server and several other Web servers 
support SSL at the server level. When both a client (typically in the form of a Web 
browser) and a server support SSL, a secure link is established. E.g., when using the 
Netscape Navigator, a user can tell by the key icon on the screen that a session is 
encrypted. The key, which is usually broken, then becomes whole. In addition, the 
first part of the URL changes from ‘http://’ to ‘https://’. 

SSL is being considered by the lETL as a possible Internet standard. Transport 
Layer Security (TLS) is the lETL working group responsible for moving security 
protocols such as SSL through the standards tracks. The first official TLS working 
group meeting was in lune 1996, before then the group was an unofficial BOP ("birds 
of a feather"). 




Fig. 3: Transport Layer Security Protocols 



5.2 TLS 

The current Transport Layer Security (TLS) protocol version 1.0 [DA97] is based 
on the Secure Sockets Layer (SSL) version 3.0 protocol [LKK96]. Like SSL, TLS is 
composed of two layers, the Handshake Protocol and the Record Protocol. The TLS 
Record Protocol is layered on top of some reliable transport protocol, typically TCP 
(see figure 3). It offers two basic services: 

• Connection confidentiality. Symmetric cryptographic techniques (e.g., DES, 
IDEA, RC2, RC4, etc.) are used for message encipherment. TLS supports both 
stream and block ciphers. In the case of a stream cipher, the plaintext is XORed 
with the output generated from a keyed pseudo-random generator. Block ciphers 
typically are used in CBC mode [ISOlOl 16]. 
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• Connection integrity. Message transport includes a data integrity check based on a 
keyed MAC. Cryptographic hash-functions (e.g., SHA-1, MD5) and the HMAC 
construction [RFC2104] are used for the MAC computations. 

The TLS Record Protocol is used for encapsulation of higher level protocols. One 
such encapsulated protocol is the TLS Handshake Protocol which allows server and 
client to authenticate each other and to negotiate an encipherment algorithm and 
cryptographic keys before the application protocol transmits or receives data. In 
particular, the TLS Handshake Protocol provides the following services: 

• Entity authentication. The peer's identities can be authenticated using asymmetric 
cryptographic techniques (e.g., RSA, DSA). TLS makes use of digital signatures 
with appendix, i.e. one-way hash-functions are used to generate the input for the 
signature algorithm. In the case of RSA, the 288-bit output of two hash-functions 
(SHA-1 and MD5) is signed; DSA mandates the use of SHA-1. Entity 
authentication can be made optional, but is generally required for at least one of 
the peers. 

• Key establishment. A shared secret is negotiated between the peers. The TLS 
Record Protocol uniquely derives the keys for encipherment and data integrity 
from the keying material established by the TLS Handshake Protocol. 

The TLS Record Protocol 

The TLS Record Protocol takes messages of arbitrary size to be transmitted, 
fragments the data into manageable blocks, optionally compresses the data, applies a 
MAC, enciphers, and transmits the result. Transmissions include a sequence number 
so that missing, altered, or inserted messages are detectable. At the receiving end, 
messages are deciphered, verified, decompressed, reassembled, and then delivered to 
higher protocol levels. 

The cryptographic techniques supported by a SSL or TLS implementation are 
specified in the form of CipherSuites. The versions of SSL and TLS which are 
exportable from the United States currently are restricted to 40-bit keys for 
encipherment and 512-bit moduli for key establishment. A special case is the 
CipherSuite TLS_NULL_WITH_NULL_NULL, where the message is not encrypted 
and the protocol operates without a MAC. 

In SSL version 3.0, the MAC computations are based on an early version of 
HMAC [BCK96]. The MAC is computed before encipherment as 

hash( K II opad || hash( K || ipad || seq_num || data )), 

where ipad and opad are repetitions of the bytes 0x36 and 0x5C to fill up one 
block for the hash-function. This proposal uses a padding of fixed length which is 
combined with the authentication key using XOR rather than concatenation (see 
section 4.1). In TLS version 1.0 this MAC computation has been replaced by the 
version of HMAC as described in RFC 2104. 
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A stream cipher directly encrypts the entire message, including the MAC. In the 
case of a block cipher, padding is added to force the length of the plaintext to be a 
multiple of the block cipher's block length. The initialization vector (IV) needed for 
the CBC mode is generated uniquely for each connection. 

The TLS Record Protocol generates keys, IVs, and MAC secrets from the security 
parameters provided by the Handshake Protocol. Those are a 48 byte master_secret 
shared between the two peers in the connection, a 32 byte client_random r^ provided 
by the client and a 32 byte server_random r,, provided by the server. A pseudo- 
random function is used to expand the security parameters into a sequence of 
arbitrary length. The construction uses two hash algorithms (MD5 and SHA-1) in a 
way designed to guarantee its security if either algorithm remains secure. 

TLS first defines a data expansion function Pj^ which uses a single hash function to 
expand a secret and a seed value into an arbitrary quantity of output: 

Pj^(secret, seed) = 

HMACj(secret, HMAC^(secret, seed) || seed) || 

HMACj(secret, HMAC^(secret, HMAC^(secret, seed)) || seed) || 



Pj^ can be iterated as necessary to produce the required quantity of data. The 
pseudo-random function PRF of TLS is then created by splitting the secret into two 
halves S, and S^ and using P^^^, to generate pseudo-random data from S, and Psj,,^.i to 
generate data from S^. In a final step the outputs of these two expansion functions are 
XORed together. The pseudo-random function uses an additional parameter 'label' 
which is an ASCII string: 

PRF(secret, label, seed) = Pjjj, 5 (S,, label || seed) Pj,u^ i(S 2 , label || seed). 

The TLS Handshake Protocol 

The cryptographic parameters for a session are provided by the Handshake 
Protocol, which operates on top of the Record Protocol. When a TLS client and server 
first start communicating, they agree on a protocol version, select cryptographic 
algorithms, optionally authenticate each other, and use public -key techniques to 
negotiate shared secrets. The Handshake Protocol can be summarized as follows: 

• Client and server exchange hello messages which are used to establish security 
parameters between client and server, i.e.. Protocol Version, Session ID, 
CipherSuite, and Compression Method. Additionally, two random values are 
generated and exchanged: client_random and server_random. 

• Client and server exchange the necessary cryptographic parameters to establish a 
pre_master_secret. Currently defined key establishment methods provide secrets 
which range from 48 to 128 bytes in length. 

• Client and server exchange certificates and other information to allow unilateral or 
mutual entity authentication. 
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• Client and server generate a master_secret from the pre_master_secret and the 
exchanged random values and provide the master_secret and the exchanged 
random values to the Record Protocol. 

• Finally, the Handshake Protocol allows the entities to verify that their peer has 
calculated the same security parameters, including key confirmation. 

The key establishment method is specified by the negotiated CipherSuite. For all 
key exchange methods, the same transform is used to calculate the master_secret from 
the pre_master_secret: 

master_secret = PRF(pre_master_secret, "master secret", r,, || r^, ). 

The length of the master_secret is truncated to 48 bytes while the length of the 
pre_master_secret varies depending on the key establishment method. When RSA is 
used for server authentication and key exchange, a 48-byte pre_master_secret is 
generated by the client, encrypted under the server's public key, and sent to the server. 
Figure 4 shows an example for the TLS Handshake Protocol using RSA key 
transport. 




Server S 



Tq, CipherSuite Proposal 



rg, CipherSuite, Cert(S) 



K = fo(pms, tc rg) 



^ Cert(C), Eg(pms), Sigc(msgs), f^(K, msgs) 
fi(K, msgs) 



msgs: all previous messages 
h, fo: functions using MD5 and SHA 





P 











Client C 

K = fo(pms, rg, rg) 



Fig. 4: TLS Handshake Protocol 



In the case of Diffie-Hellman key agreement, a conventional Diffie-Hellman 
computation is performed and the negotiated key is used as the pre_master_secret. 
Diffie-Hellman parameters are specified by the server, and may be either ephemeral 
or contained within the server's certificate. 

TLS CipherSuites 

The following tables list the non-trivial CipherSuite definitions of TLS Version 1.0 
[DA97]. In addition, the CipherSuite TLS_NULL_WITH_NULL_NULL is specified. 
Unlike SSL, TLS specifies a mandatory CipherSuite, i.e. a TLS compliant application 
must implement TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (see table 2). 
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The CipherSuite definitions of table 1 require that the server provides an RSA 
certificate that is used for authentication and key transport. The CipherSuite 
definitions of table 2 are used for server-authenticated (and optionally client- 
authenticated) Diffie-Hellman key agreement. 



CipherSuite 


Export 


Key 

Establishment 


Cipher 
(key size) 


HMAC 


RSA_WITH_NULL_MD5 


yes 


RSA 


NULL 


MD5 


RSA_WITH_NULL_SHA 


yes 


RSA 


NULL 


SHA-1 


RSA_EXPORT_WITH_ 

RC4_40_MD5 


yes 


RSA_EXPORfil 
(max 512 bits) 


RC4 40 
(40 bits) 


MD5 


RSA_WITH_ 

RC4_128_MD5 


no 


RSA 


RC4 128 
(128 bits) 


MD5 


RSA_WITH_ 

RC4_128_SHA 


no 


RSA 


RC4 128 
(128 bits) 


SHA-1 


RSA_EXPORT_WITH_ 

RC2_CBC_40_MD5 


yes 


RSA_EXPORT 
(max 512 bits) 


RC2_CBC_40 
(40 bits) 


MD5 


RSA_WITH_ 

IDEA_CBC_SHA 


no 


RSA 


iDEA CBC 
(128 bits) 


SHA-1 


RSA_EXPORT_WITH_ 

DES40_CBC_SHA 


yes 


RSA_EXPORT 
(max 512 bits) 


DES40_CBC 
(40 bits) 


SHA-1 


RSA_WITH_ 

DES_CBC_SHA 


no 


RSA 


DES_CBC 
(56 bits) 


SHA-1 


RSA_WITH_ 

3DES_EDE_CBC_SHA 


no 


RSA 


3DES EDE CB 
C 

(168 bits) 


SHA-1 



Table 1: TLS CipherSuites (1) 



DH denotes cipher suites in which the server's certificate contains the Diffie- 
Hellman parameters signed by a certification authority (CA). DHE denotes ephemeral 
Diffie-Hellman key agreement, where the Diffie-Hellman parameters are signed by 
DSA or RSA and where a certificate has been issued for use with DSA or RSA. In all 



^ The U.S. National Security Agency imposes restrictive munitions-export controls on 
encipherment technologies. Therefore, exportable versions of each of these technologies 
must make use of weaker encipherment than is permitted for domestic use. Current US 
export restrictions limit RSA keys used for encipherment to 512 hits, but do not place any 
limit on lengths of RSA keys used for digital signatures. 
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cases, client and server must have the same type of certificate, and must use the 
Diffie-Hellman parameters chosen by the server. 



CipherSuite 


Ex- 

port 


Key 

Establishment 


Cipher 
(key size) 


HMAC 


DH_DSS_EXPORT_WITH_ 

DES40_CBC_SHA 


yes 


DH_DSS_EXPORT 
(max 512 bits) 


DES40_CBC 
(40 bits) 


SHA-1 


DH_DSS_WITH_ 
DES_CBC_SHA DH_DSS 


no 


DH_DSS 


DES_CBC 
(56 bits) 


SHA-1 


DH_DSS_WITH_ 

3DES_EDE_CBC_SHA 


no 


DH_DSS 


3DES_EDE_CBC 
(168 bits) 


SHA-1 


DH_RSA_EXPORT_WITH_ 

DES40_CBC_SHA 


yes 


DH_RSA_EXPORT 
(max 512 bits) 


DES40 CBC 
(40 bits) 


SHA-1 


DH_RSA_WITH_ 

DES_CBC_SHA 


no 


DH_RSA 


DES_CBC 
(56 bits) 


SHA-1 


DH_RSA_WITH_ 

3DES_EDE_CBC_SHA 


no 


DH_RSA 


3DES_EDE_CBC 
(168 bits) 


SHA-1 


DHE_DSS_EXPORT_WITH 

_DES40_CBC_SHA 


yes 


DHE_DSS_EXPORT 


DES40_CBC 
(40 bits) 


SHA-1 


DHE_DSS_WITH_ 

DES_CBC_SHA 


no 


DHE DSS 


DES_CBC 
(56 bits) 


SHA-1 


DHE DSS WITH 
3DES_EDE_CBC_SHA 


no 


DHE_DSS 


3DES EDE CBC 
(168 bits) 


SHA-1 


DHE_RSA_EXPORT_WITH 

_DES40_CBC_SHA 


yes 


DHE_RSA_EXPORT 
(max 512 bits) 


DES40_CBC 
(40 bits) 


SHA-1 


DHE_RSA_WITH_ 

DES_CBC_SHA 


no 


DHE_RSA 


DES_CBC 
(56 bits) 


SHA-1 


DHE_RSA_WITH_ 

3DES_EDE_CBC_SHA 


no 


DHE_RSA 


3DES_EDE_CBC 
(168 bits) 

J 


SHA-1 



Table 2: TLS CipherSuites (2) 



Finally, the CipherSuites shown in table 3 are used for anonymous Diffie-Hellman 
key agreement where neither party is authenticated. Note that this key establishement 
method is vulnerable to man-in-the-middle attacks and therefore can not be 
recommended for general use. 
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CipherSuite 


Ex- 

port 


Key 

Establishment 


Cipher 
(key size) 


HMAC 


DH_anon_EXPORT_WITH 

_RC4_40_MD5 


yes 


DH_anon_EXPORT 
(max 512 bits) 


RC4 40 
(40 bits) 


MD5 


DH_anon_WITH_ 

RC4_128_MD5 


no 


DH_anon 


RC4 128 
(128 bits) 


MD5 


DH_anon_EXPORT_WITH 

_DES40_CBC_SHA 


yes 


DH_anon_EXPORT 
(max 512 bits) 


DES40_CBC 
(40 bits) 


SHA-1 


DH_anon_WITH_ 

DES_CBC_SHA 


no 


DH_anon 


DES_CBC 
(56 bits) 


SHA-1 


DH_anon_WITH_ 

3DES_EDE_CBC_SHA 


no 


DH_anon 




3DES_EDE_CBC 
(168 bits) 


SHA-1 



Table 3: TLS CipherSuites (3) 



6 The Secure HyperText Transfer Protocol 

The HyperText Transfer Protocol (HTTP) [RFC2068] is the primary protocol used 
between WWW clients and servers. The original HTTP specification has only modest 
support for security. The Web Transaction Security (WTS) working group of the 
IETF develops requirements [RFC2084] and specifications for the provision of 
security services to transactions using HTTP. 

Secure HTTP (S-HTTP) is a message-oriented communications protocol for 
securing messages that are transmitted using HTTP [RS96]. The protocol provides 
security services for transaction confidentiality, data integrity and non-repudiation of 
origin. S-HTTP offers flexibility in choice of key management, cryptographic 
algorithms and security policies by supporting option negotiation between parties for 
each transaction. Several cryptographic message format standards may be 
incorporated into S-HTTP clients and servers, particularly, PKCS-7 [PKCS7] and 
MOSS. 
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Fig. 5: Secure HyperText Transfer Protocol 



While SSL and TLS operate at the transport layer, S-HTTP supports secure end-to- 
end transactions by adding cryptographic techniques to messages at the application 
layer. Therefore, while SSL and TLS are application independent, S-HTTP is tied to 
the HTTP protocol and cannot protect applications that use protocols other than 
HTTP. On the other hand, while SSL encrypts the entire communications link 
between a client and a server, S-HTTP is able to encrypt messages on an individual 
basis. 

S-HTTP message protection may be provided in any combination of the following 
three respects: digital signatures, data integrity, and data encipherment. In addition, 
the protocol provides a simple challenge-response mechanism based on nonces, 
allowing both parties to insure the freshness of transmissions. S-HTTP does not 
necessarily require client-side public-key certificates (or public keys), as it supports 
symmetric key-only operation. Multiple key management mechanisms are supported, 
including manually shared secrets, public-key certificates and Kerberos [RFC1510] 
tickets. In particular, provision has been made for prearranged symmetric session 
keys. 

• Digital Signatures: If digital signatures are applied, an appropriate certificate (in 
X.509 or X.509v3 format) may either be attached to the message or the sender 
may expect the recipient to obtain the required certificate independently. An 
explicitly permitteded instance of this kind is a certificate signed with the private 
key corresponding to the public key being attested to (self-signed certificate). S- 
HTTP version 1.2 allows for the signature algorithms RSA [PKCSl] and DSA 
[FIPS 186]. 

• Symmetric Encipherment: For bulk encryption, block ciphers are used in CBC 
mode, for message header encipherment they are used in Electronic Codebook 
(ECB) mode [ISO10116]. Encipherment is performed as enveloping under PKCS- 
7 [PKCS7]. Currently defined encipherment algorithms are: DES, DES-EDE (2- 
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key Trmle-DES), DES-EDE3 (3-key Triple-DES), DESxE| IDEA, RC2, and 

cdmfI] 

• Key Establishment: In support of encipherment, S-HTTP defines two key 
establishment mechanisms, one using public-key key transport and one with 
externally arranged keys. In the former case, the symmetric key is transported 
enciphered under the receiver's public key. In the latter mode, the message content 
is encrypted using a prearranged session key. Alternatively, keys may be extracted 
from Kerberos tickets. 

• Message Integrity and Sender Authentication: S-HTTP provides a means to verify 
message integrity and sender authenticity via the computation of a keyed hash- 
value over the encapsulated content of S-HTTP messages. S-HTTP version 1.2 
uses the HMAC construction [REC2104] based on MD2 [RFC1319], MD5, or 
SHA-1. 

S-HTTP defines a new URL protocol designator, 'shttp'. Use of this designator as 
part of an anchor URL implies that the target server is S-HTTP capable, and that a de- 
reference of this URL involves S-HTTP processing. S-HTTP oblivious agents should 
not dereference a URL with an unknown protocol specifier, and hence sensitive data 
will not be accidentally sent in the clear by users of nonsecure clients. 

For interoperability, all S-HTTP agents must support the hash-function MD5 and 
MD5 based message authentication. As of S-HTTP/1.2, agents must also support 
HMAC-MD5. In addition, all S-HTTP agents must support outband key exchange. 
Support for encipherment is not required but only recommended; agents which 
implement encipherment must support one of the following three algorithms in ECB 
and CBC modes: DES, 40-bit RC2 and CDME [JMLW93]. Agents are also 
recommended to support signature verification; server support of signature generation 
is additionally recommended. The preferred signature algorithm is RSA. 
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Abstract. Thanks to the widespread success of the Internet, the use 
of e-mail has become common practice. More and more people are even 
using it as a primary means of communication. Unfortunately, regular 
users are not aware of the risks they are facing. If you send a regular 
letter, you can rely on the conhdentiality of its content but not so with 
plain e-mail. Each message can be intercepted by a trained computer 
user connected to the net. Indeed in this paper we will show how easy it 
is to read other people’s e-mail, and even change it without being caught. 
Thanks to an extensive use of cryptography, we can limit these risks. We 
will present and analyze an overview of the latest available standards 
and tools. 



1 Introduction 

Even in the previous era of central mainframes, there was the possibility of 
monitoring or active attacks on the serial lines which connected terminals to 
the central mainframe. However, the move to LANs in general, and Ethernet in 
particular, has made matters much worse. The Internet is a prime example of 
this. The attacks are very much easier to carry out on an Ethernet than they 
were on serial lines. Indeed, these attacks can often be carried out using just 
software, with no hardware-level interception or modification required. 

Tools that are used to check the functionality of the network (LAN analyzers, 
also known as network sniffers) can also be used to listen in on any traffic on the 
Internet. Using this software (Esniff is an example of such a public domain tool), 
it is very easy to read all e-mail messages that pass by your computer. Services 
such as anonymous remailers make it impossible to track down a message re- 
ceived through one of them. Important e-mail messages can be altered with the 
use of some hardware. The need for an electronic equivalent of registered mail 
where you can prove to an arbitrator that the letter was sent and delivered, has 
become imminent due to the emergence of services as Electronic Commerce. 

The rest of the paper is organized as follows. In section 2 we will describe 
the basic cryptographic protocol used by most of the available tools for securing 
Internet e-mail. Section 3 will elaborate on some of the vocabulary used in the 
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Internet security sector. An overview of the available systems and standards 
will be given in section 4. A commercially available product (CryptMail) that 
implements most of these standards is detailed in section 5. We will finish with 
our conclusion. 



2 Basic Cryptographic Protocol 

The properties of secret key cryptography and public key cryptography are well 
known [J- fliis real world situation we will combine both in a hybrid system 
to take advantage of their respective benefits. The basic e-mail scenario is the 
one illustrated in figure E We have two entities taking part in the protocol. We 
have the sender (A) of the message and the receiver (B). An important aspect 
is that it is a one step protocol. There is usually no prior interaction between 
sender and receiver to setup cryptographic keys or to authenticate each other. 
Basically the services that we want to offer are : 

— confidentiality of the message 

— authenticity of the receiver/sender of the message 

— integrity of the message 

— non-repudiation of origin and delivery of the message 



SA PA 




Fig. 1. Secure e-mail scheme 



To protect against an intruder listening in on the electronic mail, the mes- 
sage will be enciphered using a symmetric key algorithm. The reason for using 
symmetric technology is obvious : performance. The key that is used in this way 
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is called the Data Encrypting Key (DEK). To avoid that all of these DEK’s have 
to be distributed in an off-line way, we will use a public key system to send the 
DEK along with the message. When A sends a secure message to B, he uses B’s 
public key Pb to encipher the DEK. When B receives the message he will be 
able to decipher the encrypted DEK because he knows the corresponding private 
key {Sb)- Also he is the only one to have this key. This means that nobody but 
B can read the message (authenticity of the receiver). 

A digital signature |5] will also be applied by the sender using his private 
key (Sa)- The receiver of the message can then verify this signature using A’s 
public key {Pa)- At this moment he will be sure that : 

— nobody has changed the message (integrity); 

— sender A is the real sender (authenticity of the sender); 

— he can prove to an outsider (e.g. a judge) that A really did send this message 
(non-repudiation of origin) . 

Non-repudiation of delivery is usually not covered by the basic secure e-mail 
system. The whole procedure is illustrated in figures [U and 0 Figure [U details 
the signing and encrypting of the message and figure 0 shows how the DEK is 
transmitted. 



PB 



SB 



A 




^ B 



Fig. 2. Transmission of the DEK 



3 Internet 

3.1 Internet Standardization 

Not unlike the rest of the world, the Internet community found a need for stan- 
dardizing its protocols [3j . The procedure is however very different from the one 
used by regular standardization bodies as ISO or ITU-T. 

The top organization is called the Internet Architecture Board (lAB). The 
lAB has 2 sub-groups called IRTF (Internet Research Task Force) and IETF 
(Internet Engineering Task Force). The IRTF focuses more on the long-term 
research, while the IETF tries to solve the short-term engineering problems. 
The IETF is again divided in several workgroups. To understand the rest of this 
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paper, it is necessary to know the different stages an idea has to go through in 
order to become an Internet standard. In all there are four : 

1. Internet Draft 

2. Proposed Standard 

3. Draft Standard 

4. Standard 

The first stage is an Internet Draft. Anyone on the Internet can publish it. 
When there is sufficient interest in the community the idea will be explained 
in an RFC (Request For Comments) by one of the IETF working groups and 
it becomes a Proposed Standard. These RFCs form a set of rules with which 
product developers can build their products. To advance to the Draft Standard 
stage, there must be working implementations that have been thoroughly tested 
for 4 months. Ultimately the lAB can decide to have the RFC declared as an 
Internet Standard. Internet Standards are e.g. IP and TCP/IP. All of these 
standards are available from various Internet sources. 



3.2 Certificates (X.509) 

While public key cryptography simplifies key management a lot, it does not 
solve all problems at once. It remains essential to find a way to distribute each 
party’s public key in a safe and reliable way. This problem is usually tackled 
by introducing Trusted Third Parties (TTPs) called Certification Authorities 
(CAs), that issue certificates. 

Basically, a certificate contains a digital signature of the CA on a person’s 
name and his public key, thus binding them together. In this way the CA guar- 
antees that a particular public key belongs to a particular user. If the user can 
now prove that he knows the corresponding private key (e.g. by signing a chal- 
lenge), he will be authenticated to his correspondent. The certificate can be 
seen as a token to prove one’s identity just as a driver’s license or a passport. 
Other well known Internet security tools such as the Secure Sockets Layer (SSL) 
also use these certificates. There are now a number of commercial CAs on the 
market : Verisign, AT&T, Thawte, ... In Belgium, Belsign and Isabel offer this 
functionality to their customers. 

The ITU-T has issued a guideline (X.509) concerning certificates 0 and what 
they need to contain. The naming directives from X.500 are used. Up to now 
there have been three major releases. Version 1 originated in 1988, version 2 was 
published in 1993 and version 3 in 1996. 

A version 1 certificate looks like this : 

— Version: version number. 

— Serial number: A unique number attributed by the CA. Using this serial 
number and the name of the issuing CA, the certificate can be located. 

— Signature algorithm: Information about the algorithm used to sign the cer- 
tificate. 



Securing Internet Electronic Mail 213 



— Issuer name: The unique name (also known as distinguished name) of the 
CA. 

— Validity period: Begin time and end time of the validity of the certificate. 
This is based on Universal Time to avoid confusion about time zones. (This 
will cause problems in the year 2000, . . . ) 

— Subject name: All details about the owner of the public key that is being 
certified. 

— Subject public key information: All data needed to verify the certificate. 

— SKca- This is the signature of the CA. The public key of the CA is needed 
to verify it. 

Version 2 added two fields (Issuer unique identifier and Subject unique iden- 
tifier) to make implementation of directory access control possible. The latest 
release (V3) has made the biggest change by introducing the Extensions field. 
They have been defined to improve the functionality and to answer some specific 
requests of people using X.509 certificates. These extensions contain a criticality 
flag indicating whether a non-compliance will mean that a certificate will be 
rejected or not. Specific extensions can be defined in future standards or by user 
communities. Some of the possible extensions include: 

— Alternative naming so that the certificates can be used on Internet. 

— More information about the key : e.g. whether the key can be used for key 
management, verification of a digital signature, encryption of data, . . . 

— Other identification data such as the e-mail address of the person concerned. 

— Where the Certificate Revocation List (CRL) can be obtained. This is the 
list of the certificates that are not valid anymore. Reasons for an invalid 
certificate could be : the user has increased the bit-length of its modulus and 
needs a new public key, the user has left the organization thus rendering the 
certificate futile, or in the worst case scenario, the private key of a user has 
been broken or publicized. 



3.3 Public Key Cryptographic Standards (PKCS) 

This ‘standard’ is an initiative of RSADSI. It was written back in 1991 when the 
need for a standard, specifying how public key cryptography should be applied, 
became obvious. Other big corporations (Microsoft, DEC, ...) also support it. 
The standard is due for an update in 1997 and people are invited to submit 
their comments. In the case of electronic mail the PKCS#7 standard is very 
important. 

PKCS#7 PI is a list of specifications of how to apply public key crypto- 
graphy to offer all the requested services (confidentiality, authentication, in- 
tegrity, non-repudiation). Messages that have been encrypted using PKCS#7 
can be viewed and verified, independent of the platform or the specific mail 
client used. PKCS#7 contains both algorithm specific as algorithm independent 
encryption standards. This means that some algorithms are supported implicitly 
while others need to abide certain syntax rules to obtain interoperability. E.g. : 
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DES, RSA and Diffie-Hellman are supported completely. Furthermore PKCS#7 
also defines algorithm independent standards for digital signatures, digital en- 
velopes and certificates. 

PKCS#7 supports 2 kinds of certificates : X.509 and the scheme defined in 
PKCS#6. Basically there are 6 types of PKCS#7 messages : 

— Data 

— EnvelopedData: encrypted data 

— SignedData: data -I- digital signature 

— SignedandEnvelopedData 

— DigestedData: data -I- hash 

— EncryptedData: encrypted data without the DEK. 



3.4 Multi-purpose Integrated Mail Extensions (MIME) 

An Internet electronic mail consists of two parts : the header and the body. The 
header is a record, structured according to RFC 822 0. Until recently, the body 
could only contain messages that were written in ASCII. As a consequence all 
non-text needed to be transformed. MIME (originally defined in RFC 1521, now 
superseded by RFC 2045) installs a new format. This allows for other types than 
basic ASCII and also non textual documents. In MIME 0 several objects can 
be sent along in one mail message. 

The format of each object is called Content-Type and these are some that 
are defined : 



— Text Content-Type : to visualize textual information in different character 
sets (e.g. e, e, a, . . . ) 

— Multipart Content-Type : to send several objects in one mail message 

— Message Content-Type : contains a whole message. 

— Application Content-Type : to send binary data to a specific application 
(e.g. a .doc file to MS Word) 

— Image Content-Type : to send still images 

— Audio Content Type : to send voice and/or sound files 

— Video Content-Type : to transfer moving images. 

A new Content-Type can always be defined. Herefore one needs to apply to 
lANA (Internet Assigned Numbers Authority). lANA is the organization that 
makes sure this is done in a clear, well documented, and public way. 

The biggest problem about plain MIME is the lack of security. The solution 
was to define new Content-Types in RFC 1847 [B| for security (the Security 
Multi-parts). They are called multipart/signed and multipart/encrypted. When 
a mail client receives an encrypted mail message, the multi-parts make sure the 
message is transferred to the correct decryption engine. 
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4 Protocols 

4.1 The Oldies 

Privacy Enhanced Mail (PEM) Internet Privacy Enhanced Mail is the old- 
est protocol to secure electronic mail. The first version dates from 1985 and 
the definitive version originated in February 1993. PEM thus constitutes one 
of the standards for secure Internet e-mail. It is specified in RFCs 1421-1424 
One short-coming of PEM : it only supports mail bodies according 
to RFC 822, thus only ASCII text. 

PEM offers the four basic cryptographic services. PEM can be used with both 
symmetric key technology and public key technology. The number of algorithms 
that is supported is very limited. To obtain confidentiality, it uses the DES in 
CBC mode. To exchange the DEK and to sign the messages, RSA is applied 
together with the MD5 hashing algorithm. Unfortunately, the name they chose 
for the signature is the MIC (Message Integrity Check) and this is a term that is 
usually defined in other terms. The key management is strictly hierarchical and is 
specified in detail in RFC 1422. The key management protocol is based on X.509 
certificates and uses the X.500 directory services. To solve the problem of defining 
the CAs, PEM has defined the two top levels of CAs : the Policy Certification 
Authorities (PCA) and the ultimate arbiter, the Internet Policy Registration 
Authority (IPRA). Each PCA must list his official policy and depose this with 
IPRA. PEM is very strict with certificates and CRLs. This results in a great 
confidence in the reliability of a certificate. 

Structure of a PEM message 

Messages sent using PEM are first converted to a canonical form so they all 
follow the same conventions about white space, carriage returns and line feeds. 
This transformation is done to eliminate the effects of all the message trans- 
fer agents that modify the messages from the sender to the receiver. Without 
canonicalization, these changes would affect the results of comparing hashes, etc. 

A PEM message consists of a header and the encrypted data (body), sepa- 
rated by a blank line. 

— The first field within the header is the Proc-Type. It contains the version 
number and the services that are offered by this PEM message. 

• MIC-CLEAR : text is sent in the clear. A non-PEM compliant mail 
reader will also be able to read this message. 

• MIC-ONLY : the message has been signed and then encoded to represent 
the messages independent of the mail platform. 

• ENCRYPTED : the message has been signed, encoded and then en- 
crypted with the DEK. 

• CRL : the message contains a certificate revocation list. 

— The second field describes the Content-Domain and this is usually RFC 822 
compliant text. In case of an encrypted message we then have a first DEK- 
Info field. It specifies the symmetric algorithm used and also what initial 
value (IV) was used in the CBC mode. 
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~ With the Originator-Certificate field we can obtain the public key or the 
certificate of the sender of the message. 

— The Key-Info field is optional but is used most of the times when encryption 
is applied to the whole message. It contains the algorithm used to transfer 
the DEK and the DEK enciphered with the public key of the sender. The 
reason for this is that when the message is filed, the sender would be unable 
to decipher the message since the DEK is normally only enciphered with the 
public key of the recipient of the message. This would mean that only the 
recipient could read the message. 

— Next is the Issuer-Certificate field that contains the certificate of the issuer 
of the certificate of the sender. It is clear that when the the issuer’s CA is 
low in the CA hierarchy, we will also find all of the other issuers’ certificates 
here so that the recipient of the mail message can verify the whole certificate 
chain. 

— The MIC-Info field consists of three sub- fields. The first one gives the hash 
algorithm used, the second one the digital signature algorithm and the third 
the actual value of the signature. When the message is ENCRYPTED, the 
MIC is also enciphered with the DEK so that no one but the intended receiver 
can verify the MIC. These sub- fields are described in detail in RFC 1423. 

— One of the last fields in the header of the message is the Recipient-ID- 
Asymmetric. Analogue to the Originator-Certificate it contains the address 
of the issuer of the recipient’s certificate and its validity period. 

— The ultimate Key-Info, with the DEK enciphered with the public key of the 
recipient, completes the information needed by the recipient to reconstruct 
the whole message. 



Pretty Good Privacy (PGP) PGP is essentially the result of one man’s 
work : Phil Zimmerman. It is a complete e-mail security package that provides 
all the requested services and even compression. Even better, the complete pack- 
age (even the source code) can be obtained FREE from numerous points on the 
Internet. There also exists a commercial version in the US, sold by VIACRYPT, 
but this is not available outside the US because of the US arms export restric- 
tions. Because of the price (nil) and the quality of the available implementations, 
PGP has become very popular on the Internet and has become a de facto stan- 
dard. 

It has been involved in several controversies, mainly because the way it first 
was exported out of the US (this is an illegal act) has never been very clear. 
Phil Zimmerman has been indicted on several accounts but has not been found 
guilty. His life has been made difficult by the official US agencies because of this. 
Last year (in 1996) he founded PGP Incorporated to commercialize his work and 
to further improve PGP. Since the first releases, there have been independent 
implementations outside of the US so that the export problem has been resolved. 

The algorithms used by PGP are : RSA and MD5 for the digital signature, 
IDEA (CBC) for the bulk encryption and RSA for the key management (as in 
PEM). The latest international version (2.6.3i) supports RSA keys of up to 2048 
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bits long. IDEA is a block cipher invented by Massey and Lai ^21 that uses a 
128 bit key (rendering exhaustive key search unlikely). It is patented but PGP 
has obtained a licence to use it for free in any non-commercial applications. It 
is no coincidence that neither of these three algorithms has been designed by a 
government agency and that RSA and IDEA are offered with key-lengths that 
are much more than the ones usually allowed by the US government for export 
(512 bits for RSA and 40-56 bits for a symmetric key). 

The key management scheme implemented by PGP is pretty unique. In con- 
trary to the strictly hierarchical system of X.509, it is based on a web of confi- 
dence (trust of peers). Each PGP user locally has two files containing its key- 
rings. The public key ring is a list of all the public keys of the people the user 
usually corresponds with. Now how can a user be convinced that the public key 
of someone is genuine ? Well, he asks his friends. Each participant in the PGP 
scheme asks his friends to digitally sign his public key, thus generating some form 
of ‘certificates’. Of course they are not real certificates since they are not issued 
by a TTP, but they will suffice in closed and/or restricted communities. There 
are also PGP servers on the Internet where you can obtain public keys and they 
offer a bit more confidence. Other possibilities to broadcast your public key is 
to include it in your finger information or to put it on your WWW home-page. 
A clear advantage of this kind of system is speed. Obtaining a secure X.509 cer- 
tificate can be a very lengthy procedure and until you have it you can not start 
securing your e-mail. With PGP, you install the program, generate your key pair 
and you are on your way. Revoking a key is however very difficult, sometimes 
even impossible. The value of the non-repudiation service offered is legally very 
doubtful because of the absence of an official TTP. 

PGP message 

Here’s how one generates a PGP message. The sender first hashes his message 
and, using his private key, digitally signs the hash result. When the receiver 
eventually gets the message, he can verify this signature to convince him of 
the integrity and authenticity of the message. The signature and the original 
message are now concatenated into one single message. The resulting message is 
now compressed using the ZIP program (that uses the Liv-Zempel algorithm). 
This message is now split into 64 bit blocks and they are encrypted using IDEA 
in GBG mode with the DEK (PGP calls this the session key). The DEK is also 
encrypted with the public key of the recipient using the RSA algorithm. The 
concatenation of the encrypted blocks and the encrypted DEK, is then encoded 
using the Base-64 algorithm. The output of this is ASGII, which means that it 
can be incorporated into an REG 822 message body. At the receiver’s end all of 
these transformations can be inverted and the recipient will be able to read the 
message. 



4.2 The Newbies 

S/MIME In early 1995, several major e-mail vendors (Microsoft, Lotus, Qual- 
comm, ...) got together with RSADSI to design a secure, interoperable messaging 



218 



Mark Vandenwauver and Frank Jorissen 



standard. The result of their work is S/MIME. It stands for Secure/Multipurpose 
Internet Mail Extensions and integrates MIME with the PKCS#7 standard. 

S/MIME as of the time of writing of this article is not yet published in an 
RFC. Its current status is that of an Internet Draft HH. When the current com- 
patibility tests will have been finished successfully, S/MIME will be submitted 
to the IETF as an RFC. Several public versions have also been made available 
for testing by the general public. 

S/MIME recommends three symmetric encryption algorithms : DES, Triple 
DES and RC2. The key-size of RC2 can be adjusted to 40 bits, which is the 
maximum strength allowed for export outside of the US. As recent experiments 
and literature study have shown, 40 bit does not represent a secure system with 
the current state of the art in computing. It can be broken in a matter of hours on 
a medium size university network, or in minutes if one uses the FPGA technology 
to build a dedicated piece of hardware. 

Key management is based on X.509 certificates. Because S/MIME is new, 
it supports the Version 3 certificates (PEM e.g. does not). Evidently the RSA 
public key cryptosystem is used to generate digital signatures, exchange keys, ... 

In the draft, the new content-type application/x-pkcs7-mime is defined, to 
specify that a MIME body part has been cryptographically enhanced according 
to PKCS#7. S/MIME uses the MIME security multiparts. PKCS#7 describes 
a series of encodings to transfer messages over 7-bit electronic mail systems but 
MIME solves this with its content transfer encodings. With regular PKCS#7 
there are no restrictions on the format of the data that will be encrypted or 
signed, but in S/MIME this data needs to be a MIME entity on its own. This 
will allow the result of removing the signature and/or encryption to be passed 
on directly to the MIME engine. 



PGP/MIME PGP/MIME combines PGP with MIME, the Internet standard 
messaging protocol. It has recently completed its final phase of the lETF’s stan- 
dard process as it was published as REG 2015 Uni in October 1996. PGP/MIME 
has also been adopted by the Internet EDI Working Group to be one of the 
core components of their draft proposal to introduce EDI over the Internet. 
PGP/MIME has inherited the basic PGP properties : use of strong encryption 
without any limits on the key- length, a model of trust based on peers, ... It is 
compatible with previous PGP releases. A first commercial package supporting 
PGP/MIME was offered in February 1997 with the release of PGPMail 4.5 for 
Windows 95 and NT. 

The integration was done by using the MIME security multi-parts. Three 
new Gontent-Types have been defined accordingly : application/pgp-encrypted, 
application/pgp-signature and application/pgp-keys. The first one is used to 
send encrypted messages, the second to send digitally signed e-mail and the 
third to distribute public keys of individuals. The standard allows for messages 
to be both signed and encrypted. 

Before encrypting with PGP, the message should be written in a MIME 
canonical format The resulting MIME multipart/encrypted message will con- 
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tain exactly two parts. The first MIME body part must have a content- type 
of pgp/encrypted, while the second MIME body part will contain the actual 
encrypted data and is labeled application/octet-stream. 

When a PGP signature is applied, the data also needs to be in its canonical 
form. The digital signature is calculated on both the data to be signed and its 
set of content headers. The signature will be detached from the actual signed 
data so that the signing process won’t affect the signed data in any way. 



MIME Object Security Services (MOSS) MOSS is an integration of PEM 
and MIME. It is a framework that uses the MIME security multiparts to add 
digital signature and encryption to MIME objects. It is described in RFC 1848 
m- MOSS leaves a lot of implementation options (such as the choice of algo- 
rithms or what kind of key management to apply) open. This makes it a very 
general protocol. But this also means that it is not sure that implementations 
offered by different vendors will be able to communicate in a secure way. 

In its current form, MOSS supports two kinds of key management : one 
based on X.509 certificates and a manual scheme. Messages containing keys 
and messages containing encrypted (or signed) data are separated into different 
MIME messages. This allows for an encrypted message to be decrypted before 
the public key of the correspondent has been verified. This verification can then 
be done off-line. 

The basic structure of a MOSS message is that of a MIME multiparts mes- 
sage using the security multiparts. Before a message can be signed, it is first 
canonicalized. Then the digital signature and other control information is gen- 
erated. This control information must then be embodied in a predefined MIME 
content-type. Eventually the control information and data information body part 
will be embodied in a multipart/signed type. 



Message Security Protocol (MSP) MSP was introduced by the US govern- 
ment’s Secure Data Network System (SNDS) ^7| program. SNDS was initiated 
by the National Security Agency (NSA) to look for methods to implement se- 
curity in distributed computer systems. MSP is a protocol to provide secure 
message transfer on the X.400 network and is based within the OSI network 
model. MSP provides a large set of cryptographic services and it is the only one 
to have some form of non-repudiation of delivery. This is achieved by asking the 
recipient to send back a digitally signed acknowledgement of receipt. 

There were some plans to make a MIME implementation of MSP available. 
This Internet Draft defined a new content/type called application/msp. However 
this draft has expired and has not been updated or proposed as an RFC. 

5 Implementation in Cryptmail 

Commercial security products, as Utimaco’s CryptMail, need to evolve dynam- 
ically with their application domains. Therefore these products should be build 
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on a highly flexible and extendible architecture. To adapt products to speciflc 
security requirements, it is also important that they can easily be customized. 
Experience learns us that most of the necessary changes are done at the same 
architectural elements, so it is particularly in these areas that a product archi- 
tecture needs to be flexible. 

Four such architectural elements are: 

— the Protocol area 

— the Key Management area 

— the Algorithm area 

— the Hardware area 

The Protocol Area 

As explained in Section 4, a significant number of security protocols already 
exists. Evenmore, due to a lack of interoperability testing, and often because 
of commercial reasons, each protocol also has its different flavors, depending on 
the company who implemented it. This results in a growing need for interoper- 
ability between the different protocols and protocol flavours. This property can 
be achieved through the adoption of a structure that allows the user to choose 
which protocol he wants to use, rather than to oblige him to use a hardcoded 
one. 

The Key Management area 

Key management is one of the most underestimated aspects when imple- 
menting a cryptographic system. As already seen in Section 3.2, certificates are 
used to a great extent to achieve trust in a public key. In these certiflcates, the 
extensions that are introduced in X.509 version 3 confront implementors with 
a lot of questions. The exact meaning of an extension, although also defined 
by the ITU-T, is at present mostly determined by the first implementation of 
it. Likewise, some extensions (and even non-extension fields) are given a devi- 
ating meaning in standards such as e.g. SET (Secure Electronic Transactions), 
compared to the original definition. One might say: if the envisaged application 
doesn’t match the protocol standard, one abuses the standard to make it fit to 
his application’s needs ! Also, anyone is able to include new, proprietary exten- 
sions in a certificate. Of course, other applications then need to process those 
extensions. This may become unfeasible without the prior establishment of a 
limited set of interoperable profiles. 

The Algorithm area 

There are several reasons for having an architecture that allows algorithms to 
be both selectable and replaceable. Different users have different security needs, 
different local standards, etc.... There usually is a trade-off between the delay 
resulting from encryption, and the security level of the message. This means that 
key lengths and algorithms need to be changeable. Cryptographic algorithms also 
are subject to attacks, and nobody can guarantee that what is at present a secure 
algorithm, will also remain secure in the future. 

The Hardware area 

To obtain the high security level required for applications such as financial 
transactions, products may need to interface to hardware devices to securely 
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store secret keys. However, many types of hardware devices exist. Some exam- 
ples: smart cards, SmartDisks (TM), cryptographic boards and servers. Also, dif- 
ferent smart cards may have different functionalities and characterisitics. Rather 
than obliging a customer to use one specific type of smart card, a security prod- 
uct needs to incorporate the hardware device chosen by the customer in a fast 
and transparent way. 

Problems of customization 

From the above, one can understand the need for a flexible product (architec- 
ture). There is however also a drawback to this. A user may get confused by all 
the options he can choose from, especially when he isn’t familiar with technical 
details of security. Also, all these options result in a vast amount of functionality 
that is not used after some start-up decisions are made. 

Solution 

The customer should only get what he really needs. This involves e.g. that 
a customer who has decided to only use PKCS#7 will only get the software 
for this protocol. This is realised by making use of a switching module. This 
switching module is able to scan all DLL’s that are present on the system and 
generates a table with all the functionality that is present. According to this 
table, the switching module reroutes the calls to the encryption-decryption layer 
to the right functions. If he needs to make use of some functionality that is not 
present on the system, he will first try to remap it to other functions. If this 
doesn’t work, the application will issue a warning. Another functionality offered 
by the switch table, is the customisability of the GUI. The application decides 
which options and buttons are present based on the functionality present in the 
table. All custom libraries are also dynamically loaded. This architecture has 
some clear advantages. 

1. The ability to create a customised product. Each customer only gets the 
DLLs that he will use. 

2. The reduction of the time needed to start the application. Only the support- 
ing framework now needs to be loaded and all the other libraries only are 
loaded when they are really used. 

3. A system can also keep track of which customer has received what part of 
the software. This enables the support division to focus on a much smaller 
base. 

Cryptmail 

PKCS#7 and S/MIME are typical examples of standards in which the above 
switching architecture can be employed usefully. In the following paragraph, the 
corresponding requirements in the Crypt Ware Architecture will be discussed. 

1. As said in Section 4.2, S/MIME is based on PKCS#7. Instead of having 
two libraries, one for S/MIME and one for PKCS#7, that fully implement 
the protocols, the S/MIME library uses the PKCS#7 library. This means 
that the S/MIME module also uses the switching module to map its crypto- 
graphic functions back to the PKCS#7 DLL. The choice of PKCS#7 in 
the implementation is done by using so called ’’set option” commands, that 
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are able to choose a certain protocol. When sending a certain message, this 
library also can point to a sort of standard message header. This has the 
advantage that when the customer wants to change some standard values in 
the header, only a template file needs to be copied onto the system of each 
user. 

2. As mentioned in Section 4.2, PKCS#7 uses the X.509 certificate layout, 
without the need for certain extensions. In case of S/MIME however, some 
standard extensions need to be present concerning the use of the certificates 
and under which policy they have been issued. This results in an extra library 
to be loaded, to process these extensions. Again policy decisions can be based 
on a separate file, to enable the system administrator to quickly change the 
policies that are accepted to sign a certain message. 

3. S/MIME and PKCS#7 specify the use of different algorithms that need 
to be accepted in each compliant implementation. When some changes to 
the standard are made, and other algorithms become mandatory, an extra 
library only needs to be copied onto each system to upgrade the system. 
This results in a big improvement over the distribution of a new application 
to each customer. 

4. Currently, no support for hardware is specified in the standard. But, as 
hardware support is frequently required nowadays, and in the context of 
PKCS#7 it is under investigation (see Section 3.3), it is likely that this 
will be added in a future version of the standard. Using the CryptWare 
architecture, this will also result in a new library that needs to be present. 

6 Conclusion 

Just as we have seen an explosion in the number of Internet users over the last 
years, there has been an increase in the number of solutions for securing elec- 
tronic mail. Two years ago, people could choose between PEM and PGP. PGP 
was the market leader, mainly because of its availability and price (FREE). 
Now that people are committing themselves to the use of e-mail for business 
appications, the concern for security has grown. Due to the shift towards multi- 
media and the importance of user friendliness, three new schemes were proposed 
recently. PGP/MIME inherits most of the benefits from PGP but keeps on pro- 
moting its web of confidence scenario. While this can be used within a company 
or for EDI (when previous bilateral agreements are signed), it is not a good so- 
lution for electronic commerce. It will be interesting to see how PGP will evolve 
now that Phil Zimmerman has founded PGP Inc. 

On the other hand, both S/MIME and MOSS use X.509 certificates. This 
means that the level of confidence in the other party’s public key will be higher 
for secure (level 3 in the Verisign language) certificates. MOSS suffers from the 
fact that there are few implementations available. S/MIME is pushed by some of 
the largest companies (Microsoft, Netscape, . . . ) and will be incorporated in most 
of the commercially available secure e-mail tools. The reason for including MSP 
in this picture is that it provides non-repudiation of delivery. This is essential 
when using e-mail for executing secure electronic transactions. 
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Abstract. Security requirements and services of a mobile communication 
system differ, due to the radio communication between the user and the base 
station, extensively from those of a fixed network. There is no physical link in 
the form of a (fixed) telephone line between the user and the local exchange, 
which could serve to "identify" the user for routing and charging purposes. 
Authentication hy means of cryptographic procedures is thus required to stop 
impostors from taking on the identity of somebody else and "transferring" calls 
and charges. Eavesdropping on the radio path, intercepting data or tracing the 
whereabouts of a user by listening to signalling data are other serious threats. 
This paper discusses countermeasures designed into the Global System for 
Mobile communications, the role of the Subscriber Identity Module as a 
security device and security aspects related to the management of the secret 
authentication keys. 



1 Introduction 

The specification of the Global System for Mobile communications (GSM) began 
in 1982 with the formation of the Groupe Special Mobile (GSM) by the European 
Conference of Postal and Telecommunications Administrations (CEPT). In 1989 
GSM became a Technical Committee of ETSI, the newly founded European 
Telecommunications Standards Institute. This allowed industry to take a more active 
role in the standardisation process through "direct" participation. The eleven 
SubTechnical Committees specify all aspects of this digital cellular system from 
services and facilities to the interface between a mobile and a subscriber card. They 
are also responsible for the Gniversal Mobile Telecommunications System (UMTS). 
The incorporation of this next generation system into the scope and work of the 
Technical Committee GSM in 1992 also led to the change in the acronym for the 
committee from GSM to SMG (Special Mobile Group). 

GSM offers the user the possibility to roam across networks and national 
boundaries. A roaming agreement between the two operators is the only real 
prerequisite. Though the implications of roaming for network management and 
billing procedures are manifold one could, from a security point of view, think of the 
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foreign network as a remote part of the subscriber's home network. While the data 
needed for checking the authenticity of a user are generated by the home network, the 
verification of the data and thus the access control to the (visited) network are 
handled locally by the Visitor Location Register (VLR) where the (roaming) 
subscriber is temporarily registered. 

All the necessary information about the subscription as well as the network 
specific authentication algorithm and the subscriber specific authentication key are 
contained in the subscriber card, the Subscriber /dentity Module (SIM). The split of a 
Mobile Station (MS) into a radio part, the Mobile Equipment (ME), which does 
normally not contain any subscription related information, and a subscription part, the 
SIM, gives the network operator, on whose behalf the SIM has been issued, the 
complete control over all subscription and security related data. The SIM is thus an 
integral part of the overall security system of each and, therefore, all networks and a 
token for the mobility of the subscriber. 

Listening to the communication between a Mobile Station and a base station can 
hardly be prevented. One of the novel features of GSM is the enciphering of this link 
to protect user and signalling data against eavesdropping. Special ciphers have been 
developed for this purpose. They are integrated into the ME as a dedicated piece of 
silicon. The cipher key is derived by the SIM during the authentication process. To 
authenticate a SIM the network has to know its (claimed) identity. As this has to be 
sent over the air interface, temporary identities are used to counteract the threat of 
tracing the user's whereabouts. 

After discussing security issues and the security services provided in a GSM 
network, we look at the role played by the Subscriber Identity Module as a secure 
device for storing keys and algorithms. This is followed by a consideration of aspects 
related to key management, a list of abbreviations with definitions, and the 
references. The article is based on the current GSM Phase 2 specifications with some 
particularities of Phase 1 being mentioned. For more information on the GSM system 
the reader is referred to [5,16]. 

Threat analysis and security services are similar in nature for most mobile 
communication systems. To obtain a deeper insight into these issues the interested 
reader is referred to [3] which contains a threat analysis as well as the specification of 
the security services for DECT, the Digital Enhanced Cordless Telecommunications. 
The second edition of [3] contains several annexes dealing with the security of the 
interworking between DECT and GSM. It also discusses the functionality of the SIM 
and the DAM [4] in such a system. The DECT Authentication Module (DAM) plays a 
role similar to that of the SIM. 
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2 Security Issues 

The main security threats to a mobile communication system are probably the 
illegitimate use of a service and the interception of data on the air interface which 
could result in a variety of threats to the profitability of the system, the privacy of the 
user and the integrity of either. 

It is clearly important that billing should always be possible and that only the 
subscriber, who has caused the charge, is billed for it. The purpose of a masquerading 
attack may, however, not just be to defraud the network by having the charges 
transferred to any subscriber but to impersonate a specific subscriber. This could then 
be used to "show" that that subscriber made a call from a particular place at a 
particular point in time. Authentication of the subscriber by cryptographic means and 
the use of a security device for storing data and algorithms needed for the 
authentication process are thus essential requirements. 

At the set up of a session the identity of the subscriber has to be sent to the network 
by the MS. Furthermore, due to the constant update of the location of an MS, which is 
necessary for a proper and timely delivery of mobile terminated calls, the network has 
to know the location of the subscriber card down to the cell in which the MS 
containing this card is active, that is, switched on. (The area covered by a cell may 
range from a few hundred metres to about 35 km.) Measures need thus be taken to the 
protect the confidentiality of the identity of the subscriber. 

The interception of user data or user related signalling information may result in a 
loss of confidentiality of this data or of the user's identity with respect to the outside 
world. User data are transferred over traffic channels as well as over signalling 
channels. The signalling channels carry, apart from obvious user related signalling 
information elements such as the called and the calling telephone numbers and user 
data in form of short messages. These allow the user to receive and send messages of 
up to 160 bytes over the radio link without activating a traffic channel. 

To protect network operators and users against attacks inherent in any unprotected 
radio link, the implementation of the following security features is mandatory: 

• subscriber identity confidentiality; 

• subscriber identity authentication; 

• user data confidentiality; 

• signalling information element confidentiality. 

The functional description of these security features is contained in GSM 02.09 
[7]. A standard on the secure management of networks [12] has been elaborated by 
SMG6 which deals with operation and maintenance issues. 
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3 The Security Services 

A functional description is by its very nature not sufficient to ensure 
interoperability between networks and the same level of security being achieved 
throughout the system. The specification of the security related network functions and 
the parameters for the cryptographic algorithms needed to provide above services are 
contained in GSM 03.20 [9] which forms the basis for the implementation of these 
features. 

From a user point of view it is not relevant whether the user-related data to be 
protected are contained in a traffic or a signalling channel. We may therefore say that 
GSM provides three security services: 

• temporary identities for the confidentiality of the user identity; 

• authentication for the corroboration of the identity of the user; 

• enciphering for the confidentiality of user-related data. 

3.1 Temporary Identities 

When a user logs into a network the identity of the subscriber has to be made 
known to the network. Rather than sending the International Mobile Subscriber 
Identity (IMSI), which uniquely Identifies the subscriber world-wide, a temporary 
identity is transmitted by the MS in most instances. 

The purpose of temporary identities is to deny an intruder the possibility of gaining 
information on the resources used by a subscriber, preventing the tracing of the user's 
location and matching user and data transmitted. To achieve this "the IMSI is not 
normally used as an addressing means on the radio path" [9]. Clearly, the IMSI has to 
be used for the set up of a session if there are no other means to identify a mobile 
subscriber. This is, for instance, the case when the subscriber uses the SIM for the 
first time or at a data loss in the VLR where the subscriber is temporarily registered. 
When the SIM is used for the first time, the MS will read the default Temporary 
Mobile Subscriber Identity (TMSI) stored in the SIM at pre-personalisation (see 5.3) 
and send this value to the VLR. As this is a default value, the VLR will request the 
IMSI from the MS. It then assigns a TMSI to the subscriber and transmits this (after a 
successful authentication and the activation of the cipher) in an enciphered form to 
the MS. The MS deciphers the data and stores the TMSI and information about the 
present location in the SIM. At the next log-in the TMSI will be sent in clear to the 
network, a new TMSI will be assigned by the VLR and sent to the MS as enciphered 
data. Enciphered TMSIs can thus not be matched against TMSIs in clear text. 
Furthermore, the TMSI must be updated at every location update and will be changed 
several times during a session. 

Though the TMSI consists of only five digits, the subscriber is uniquely 
identifiable. For the TMSI is unique within the location area where the MS moves, 
and the location area identity (LAI) is always used in conjunction with the TMSI. As 
TMSI, IMSI and LAI are stored in the VLR the identity of a subscriber moving to a 
different VLR can easily be established by the new VLR. It knows the "old" VLR 
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from the LAI which the MS has sent together with the TMSI at log-in and it then 
obtains the subscriber's IMSl from the old VLR. If there is no malfunctioning of the 
system the IMSI will not be used (over the air) for call set up after the initial session. 
GSM 03.20 [9] specifies eight procedures for the allocation of a new TMSI 
depending on the structure of the network(s) and possible data losses. 



3.2 Authentication of the Subscriber 



Authentication is the corroboration that an entity is the one claimed or, in this 
context, the verification of the identity of the SIM. The purpose is "to protect the 
network against unauthorised use" [7] and thus to ensure correct billing and to 
prevent masquerading attacks. Subscriber authentication is of major interest to each 
operator and all management issues not affecting the interoperabilty of GSM are left 
to the sole discretion of the operator. 

The authentication algorithm (denoted by A3) is implemented in the 
Authentication Centre (AuC) of the home network, the Home Public Lands Mobile 
Network (HPLMN), and in the SIM. For operators not using a proprietary algorithm a 
proposal for an authentication algorithm is available upon appropriate request [9]. To 
achieve interoperability between all the networks and compatibility of the suppliers 
the parameters to be satisfied by the algorithm A3 and the authentication protocol 
have been specified by SMG [9]. The method employed between the HLR/AuC and 
the SIM is a Challenge-Response mechanism using "non-predictable numbers". 



SIM/ME Radio path VLR HPLMN 

HLR/AuC 

Retrieve Ki from IMSI 



Ki 



RAND Ki 




Parameters: Ki: 128 bits; RAND: 128 bits; SRES: 32 bits; run-time of A3: 

<500ms. 

Figure 1 : Authentication procedure 
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Figure 1 shows the basic procedure for the authentication of the SIM by the 
network. It should be noted that the role of the VLR is in [9] attributed, more 
generally, to the BSS/MSC/VLR parts of the system. 

After establishing the identity of the SIM (see above) the VLR sends an 
authentication request to the HPLMN. This request contains the IMSI which is 
needed to retrieve the secret, individual subscriber authentication key Ki used in the 
protocol. The HPLMN then generates a non-predictable number RAND which is sent 
to the MS as a challenge (via the VLR). To compute the "Signed RESponse" SRES to 
the challenge RAND the SIM uses the algorithm A3 with RAND and the key Ki 
stored in the SIM as input data. SRES is then transmitted to the VLR which may be in 
a foreign network. There it is compared with the value SRES computed by and 
received from the AuC of the HomePLMN. The AuC has used the operator specific 
algorithm A3 with the same RAND and the key Ki which is associated with the 
identity claimed by the subscriber. The MS is granted access to the network by the 
VLR only if the value for SRES received from the MS equals the value received for 
SRES from the HLR/AuC. Only in this case it can be assumed that the SIM is in 
possession of the right subscriber key Ki and that its identity is the one claimed. 

Upon request for security related information the VLR usually receives from the 
HLR/AuC a set of pairs consisting of RAND and the corresponding SRES. 
Accompanying these pairs is always a new cipher key Kc which has been computed 
using Ki and the same non-predictable number RAND with an algorithm called A8 
(see 3.4). The challenge RAND and the derived values SRES and Kc are called an 
authentication triplet or a set of security related information. 

When a user has moved to a new VLR, the new VLR will normally establish the 
subscriber's identity by requesting the IMSI from the old VLR (see 3.1). In both 
Phase 1 and Phase 2 the old VLR transfers, together with the IMSI, any unused 
triplets to the new VLR. This speeds up the authentication procedure as the new VLR 
can only send a request for triplets to the subscriber's HLR/AuC after it has learned of 
the "real" identity of the subscriber which is through this request to the old VLR. 

In Phase 1 each triplet is used only once and must be discarded after being used. 
Both restrictions do not apply to Phase 2. The re-use of security related information in 
failure situations such as a breakdown of the link to the HLR is considered to improve 
the security level. In Phase 1 the VLR may in such a situation permit outgoing calls 
without further authentication if the MS has been successfully registered and 
authentication triplets cannot be obtained from the HLR. 

Another Phase 1 option which has been deleted from the Phase 2 specifications is 
that the HLR/AuC may transmit, upon request for security related information, the 
secret subscriber key Ki to the VLR for the local generation of the triplets. It is 
however recommended to restrict this procedure to the HPLMN (clause 3.3.2 of GSM 
03.20 Phase 1). Using this option would certainly reduce the traffic with the HLR and 
improve the availability of the service in situations where the link between the HLR 
and the VLR is unreliable. The security implications are, however, severe. The 
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(secret) algorithms A3 and A8, which are used to generate SRES and Kc, need to be 
implemented in the VLR in a secured environment and secret keys have to be sent 
from the HER to the VLR. The cryptographic protection of these links, which are 
natural places for an attacker to collect IMSIs and corresponding keys, may not 
always be possible. In the case that this method was used for roaming the home 
network would have to disclose algorithms and keys to the other operator or to supply 
black boxes and sending the keys enciphered. 



3.3 Authentication of the Network 

Unlike DECT, the security features of which have been specified only in the early 
90s, GSM does not provide the means for the SIM to authenticate the "network". 
When specifying the security features of GSM this functionality was considered to be 
of limited use and the idea of administrating data in the SIM over the air interface had 
not been of widespread interest. The latter has changed considerably during the last 
few years and the finalisation of the so-called SIM Application Toolkit [11] has led to 
a revival of this dormant topic. 

The SIM Application Toolkit offers a platform for new operator specific services 
such as the downloading of data into the SIM by use of the short message service. A 
typical example would be the update of service numbers or the creation of new data- 
fields in the SIM. The downloading of the data would be transparent for the Mobile 
Equipment. The SIM would "unwrap" the short message and execute the command 
internally without the request by its master, the ME. Depending on the data to be 
updated and the commands to be executed, the SIM has to be sure that the sender of 
the short message as well as its contents are genuine and have not been altered in an 
unauthorised manner. An obvious way of achieving both is to protect the contents of 
the short message by means of a message authentication code (MAC) [14]. The MAC 
is sent as part of the short message and verified by the SIM prior to any action coded 
in the short message. As calculation and verification of the MAC require a secret key 
known only to the sender (network) and the receiver (SIM), the SIM can also 
indirectly authenticate the network. If the verification of the MAC is positive the SIM 
can assume that the sender is the one claimed. 

The authentication of sender and data are clearly not the only security relevant 
questions one has to discuss when using the short message service for the 
administration of SIMs. Other issues are, for instance, replay attacks and problems 
which might arise if commands and data are contained in more than one short 
message. As the SIM Application Toolkit is part of the GSM Phase 2 + programme 
and thus optional, one could argue that the security of these features is up to the 
specific operator and its suppliers. On the other hand, security holes in one network 
may have an effect on the system in general, even if it is "only" from an image point 
of view. Work has now started on providing a security standard for the short message 
service as part of the SIM Application toolkit. 
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3.4 Enciphering 

The purpose of this security service is to ensure the privacy of the user information 
carried in both traffic and signalling channels and of user-related signalling elements 
on the radio path. The activation of this service is controlled by the network. It is 
started by the base station by sending a "start cipher” command to the MS. A standard 
cipher algorithm A5, now denoted by A5/1, is contained as a dedicated piece of 
silicon in mobile equipment and base stations. This algorithm can be implemented 
using about 3,000 transistors [2]. Since March 1993 a second cipher called A5/2 is 
available. Not more than seven version of the A5 will however be defined [9]. 

A form of stream cipher is used to encipher the layer 1 data. The plain text is 
organised into blocks of 114 bits as this is the amount of data which is transmitted 
during a time slot. The key stream, which is the sequence of bits to be XORed 
(modulo 2 addition) with the data block, is produced by the algorithm A5 as an output 
block of 114 bits. For synchronisation and other implementation details the reader is 
referred to [9] . 

Figure 2 below also shows the generation of the cipher key Kc, which controls the 
generation of the key stream by the algorithm A5. This key is derived in the SIM as 
part of the authentication process using the network operator specific cipher key 
generator A8 and the same RAND and Ki as in A3. 

RAND Ki 



A 




Parameters: Ki: 128 bits; RAND: 128 bits; Kc: 64 bits. 
Figure 2: Cipher key generation and enciphering 
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Binding the generation of Kc to the authentication process has several advantages. 
No additional input data are required. Bypassing the authentication procedure by, say, 
manipulating the comparison of SRES in the VLR will, in general, not allow a 
fraudulent use of a service. The MS and the base station would use different cipher 
keys resulting in an indecipherable garbled message. 

It is also worth noting that the authentication algorithm A3 as well as the cipher 
key generator A8 compress the non-constant input data RAND from 128 bits to 32 
bits (SRES) and 64 bits (Kc), respectively. Even if A3 and A8 are one and the same 
algorithm (denoted by A38), a compression takes place. This implies that the 
challenge RAND can not be derived just from the output data (Kc, SRES) and that the 
SIM can not be used for enciphering or deciphering data. 



4 The Subscriber Identity Module 

The Subscriber Identity Module (SIM) is a security device which contains all the 
necessary information and algorithms to authenticate the subscriber to the network. It 
also adds a new dimension of mobility to the subscription as it is a removable module 
and may be used in any mobile equipment (subject to the SIM having the right 
format). The functionality of the SIM is described in GSM 02.17 [8] while its 
interface to the ME is specified in GSM 11.11 [10a,b] (reference [10b] contains 
additional features and services which are part of the optional GSM Phase 2 + 
enhancements). 



4.1 General Properties 

To achieve its main task of authenticating the subscriber to the network, the SIM 
contains a microcomputer with on-board non-volatile memory. The SIM is a smart 
card which comes in two formats. The ID-1 SIM has the size of a credit card. The 
Plug-in SIM, which is used mainly with mobiles too small to support an ID-1 SIM, 
may be "obtained" from the latter by cutting away excessive plastic and thus reducing 
the size to 25 mm by 15 mm (see figure 3). The electrical and mechanical interfaces 
are, with the obvious exception of the size of the Plug-in SIM, in line with the 
relevant International Standards for Integrated Circuit (IC) cards [10, 13]. In some 
instances more stringent conditions were agreed upon to cater for the needs of the 
environment the SIMs are used in. These include the temperature range the card has 
to satisfy and the power consumption of the microcomputer. 
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ROM up to 20 kByte 
RAM up to 5 12 Byte 
EEPROM up to 16 kByte 



Figure 3 : SIM formats and memory provided 

The microcomputer consists of a CPU and three types of memory. The masked 
programmed ROM (Read Only Memory) usually contains the operating system of the 
card, the code for the GSM application and the security algorithms A3 and A8. The 
RAM (Random Access Memory) is used for the execution of the algorithms and as a 
buffer for the transmission of data. Subscription specific data such as Ki and IMSI, 
network related information such as TMSI and LAI, which need to be updated by the 
network, and subscriber related information such as abbreviated dialling numbers, 
which have to be changeable by the subscriber, are stored in non-volatile erasable 
memory (EEPROM, Electrically Erasable Programmable Read Only Memory). The 
memory space offered by present day smart card chips is given in figure 3. For more 
information on smart cards the reader is referred to [17]. 
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4.2 Access to the SIM 

The operating system of the card controls the access by the outside world, which 
may be an ME or any other interface device, to all data stored in the card. Access is 
mainly by reading or updating the respective memory cells. GSM has specified five 
(independent) access conditions. These are NEVER, ALWAYS, ADM, PIN and 
PIN2. The access condition ALWAYS means that no security restriction holds. The 
IC Card Identification number, which identifies the SIM and is also printed on the 
card itself, may ALWAYS be read over the interface but will NEVER be permitted to 
be updated. The definition and use of ADM is up to the discretion of the operator. 
This may be one of the five access conditions or a specific procedure which can only 
be executed by an appropriate administrative authority. PIN and PIN2 are discussed 
in the following section. 

The interface to the outside world consists of eight contacts two of which are 
reserved for future use [13]. One of the remaining six contacts is needed for cards 
requiring an external Programming Voltage. For the GSM application this is not 
connected to the microcomputer as all SIMs have to derive the programming voltage 
from the Supply Voltage (Vcc) by means of an internal charge pump. Apart from the 
Vcc contact there are thus only four contacts to access the microcomputer electrically 
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by "normal" ways. These are used for the Reset of the chip, the Clock to drive the 
chip, Ground and the Input/Output of data. Having only one I/O channel certainly 
restricts the data throughput but is of an advantage from a security point of view. At a 
Baudrate of 9,600 bits/sec the (theoretical) upper bound for the card throughput is 
3,200 bits/sec. This is due to the half duplex transmission protocol and other 
overhead. 



4.3 User Access to the SIM 

User access to the SIM is controlled by a Personal /dentification Aumber (PIN). 
The PIN, which can be freely chosen within the range of 4 to 8 digits, may he 
changed hy the user as often as felt necessary. This is possible since the PIN is stored 
in the EEPROM of the chip and the comparison of the value presented by the user 
with the PIN stored is done by the microcomputer of the SIM; the PIN does not leave 
the chip. To protect the user against trial and error attacks, the microcomputer 
controls the number of consecutive false PIN entries. After three such entries the card 
will be blocked and refuse to work, even if it has been removed in between attempts 
or a different ME is used. A blocked SIM does not even send its identity in form of 
the TMSI or IMSI to the ME as these data-fields are protected against reading by the 
security level PIN. The user can only "unhlock" a SIM by presenting the so-called 
PIN Unblocking Key (PUK) to the card together with a new PIN. The PUK is simply 
another identification number consisting of eight digits. After 10 consecutive wrong 
PUK entries the SIM is permanently blocked. As the PUK cannot be changed by the 
user it could also be stored in the home network and given to the user if the necessity 
arises (subject to certain security conditions being satisfied). It should also be recalled 
that the access of a SIM to a mobile service can easily be suspended by blacklisting 
the subscription in the HLR/AuC. 

Another novel feature is the option to disable the PIN check. The network operator 
or the service provider, if the network operator so decides, may set a flag in the card 
which allows the user to switch off (and on) the PIN check. If the PIN check has been 
disabled by the user, the SIM will not request the presentation of a PIN at the 
beginning of a session and access control to the SIM and thus the network (if the card 
is not blacklisted in the HLR/AuC) is based merely on the possession of the card. 

The introduction of certain new services in Phase 2 has changed the role of the 
PIN. A SIM supporting the fixed dialling number service will not allow the user to 
call numbers other than those stored in the SIM. Advice of Charge may in certain 
scenarios used not only as an advice to the customer about the number of units spent 
but also for limiting the amount of money spent by the user. Typical examples for 
such applications would be SIMs issued to drivers of a fleet of lorries or to children. 
Changing the fixed dialling numbers or resetting the charge counter should clearly 
not be under the control of the user (though it may be under the control of the 
subscriber) and thus not under the control of the PIN. For the update of the contents 
of these and other data-fields independently of the normal PIN, PIN2 and the 
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accompanying PUK2 have been introduced. Due to the nature of PIN2 as a means to 
protect data-fields the user should not have access to, it is not possible to disable the 
check of PIN2 though its value may, of course, be set to a trivial one or equal to the 
one of the PIN. 

It should be mentioned that using the Advice of Charge service for charging 
purposes or the issue of pre-paid SIMs is, from a security point of view, not 
advisable. As the interface between the ME and the SIM is not secure it would be 
comparatively easy to manipulate the interface so that the charges do not reach the 
SIM. This would not be noticed by the network as the system does not provide the 
means that the card can acknowledge the receipt of the information. Though this 
could be achieved with a short message being generated by the SIM using the SIM 
Application Toolkit platform it is doubtful that effort and overhead would justify the 
purpose. 



5 Key Management 

In this section we consider some of the aspects concerning the authentication 
centre (AuC) and the handling of the individual subscriber authentication keys. 



5.1 The Authentication Centre 

The specific security and administrative requirements for an Authentication Centre 
are not standardised but left to each network operator as security matters are up to the 
discretion of the operator. GSM 03.20 [9] only states that the individual subscriber 
authentication keys Ki are stored in an AuC and that the AuC also contains the 
authentication algorithm(s) A3 and the cipher key generating algorithm(s) A8. 

A malfunction or a temporary loss of the information contained in an AuC would 
have severe consequences for the security as it affects the generation of the 
authentication triplets. Since other information about the subscriptions, including 
possibly black lists of barred subscriptions, is contained in the HER, it is only logical 
to "integrate" the AuC into the HER. In networks with more than one HER the back- 
up and overload facilities could be distributed over several HLR/AuCs. 

Key management is a major issue when designing an AuC. The method used for 
generating and storing potentially several million individual subscriber authentication 
keys and the handling of the authentication requests are of importance for both the 
secure and the smooth running of the network. 
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5.2 Key Generation 

There are two standard methods to generate keys. They may be generated by using 
a random number generator or by deriving them from user related data with the help 
of an algorithm under the control of a master key. Both methods have their 
advantages and disadvantages which we will briefly discuss in the light of the 
boundary conditions given in GSM 03.20 [9]. 

Deriving a key. The main advantage of deriving a key from non-secret 
(subscription) data under a master key MK is that such derivable keys need not be 
stored and that the back-up of the subscriber keys is reduced to the back-up of the 
master key. No data banks containing secret information are thus required in the AuC 
nor at the back-up facility. When an authentication request comes from the VLR, the 
AuC would just load the relevant data, say the IMSI, into the algorithm and derive the 
individual subscriber authentication key Ki from this data using the top secret master 
key MK. Ki would then be loaded with the random number into A3 and A8 for the 
generation of SRES and Kc. 

The selection of the algorithm and the input data to go into this algorithm depend 
on several boundary conditions. These include the length of the key Ki (128 bits) and 
whether one of the algorithm(s) already available in the AuC is suitable or whether a 
specific algorithm should be employed. Considering the number of authentication 
requests the algorithm has to be fast if one wants to avoid "queues" or having too 
many secured boxes running in parallel. A natural candidate for the input data would 
be the IMSI which consists, however, of only 15 digits each one coded on half a byte 
[10]. A natural candidate for the algorithm is the DBA [1], often referred to as DBS, 
which is also available in hardware. As the key Ki consists of 128 bits and the DBA 
has an input block of 64 bits one has to "expand" the IMSI to 16 digits and apply the 
DBA twice. To improve the distribution of the derived keys (with respect to the set of 
strings having 128 bits) one could first reduce the length of the IMSI to 10 digits by 
removing the 5 digits which are identical for all IMSIs of the HPLMN and use parts 
of other subscription related data for the remaining 6 digits. Two possibilities to 
obtain Ki from this value UD representing the user data are given below, where 
denotes the concatenation of the two terms and UD' (user) data which is different 
from UD: 

(i) Ki = DBA MKleft (UD) II DBA MKright (UD) , and 

(ii) Ki = DBA mk(UD) II DBA mk (UD'). 

In the first case the master key consists of two parts of 64 bits each, while in the 
second case the same 64 bit key is used for the calculation of the both parts. 

Though this method may look very elegantly at first glance it has a few 
undesirable effects if it is not managed with extreme care from both an administrative 
as well as a security point of view. 
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The main problem is of course to keep the very secret key MK secret. Anybody 
coming into possession of this key could, if he/she also knows the method of deriving 
Ki and the secret algorithms A3 and A8, compromise every card issued under MK. 
One could reduce the potential damage by replacing the master key periodically. As a 
consequence, more secret keys have to be maintained and a logical link has to be 
established between the respective master key and the subscription (this could be 
done by coding the key number as part of the IMSI). The number of master keys 
being used at the same time depends on the length of time each one of them has been 
employed for generating subscriber authentication keys as well as on the validity 
period of those SIMs. 

The method can also lead to the production of "identical” SIMs. If the same IMSI 
has been used by mistake to generate the keys for two SIMs, these SIMs will be 
identical from a security point of view. They contain the same IMSI and Ki. Though 
this should normally be noticed at the activation of the "second" SIM the implications 
are such that it puts a big question mark against the whole method. 

One can avoid the risk of producing identical SIMs by combining subscription data 
with random data. In this variation the input data UD would consist of the IMSI or 
parts thereof together with a string of random bits. This is however somewhat 
counterproductive to the main reason for choosing the method in the first place. For 
this random data has to be stored, though not enciphered, against the IMSI (or other 
identification data) in a data bank in the AuC. On the other hand, this variation has 
the advantage that the random data is not publicly available and not related to the 
subscription. A compromise of the master key does, therefore, not automatically 
impair the security of the whole system. One could even go a step further and use 
only random data for the input to the algorithm. 

The key as a random number. Using a random number generator to produce the 
subscriber authentication keys insures that all strings consisting of 128 bits are 
equally likely. This is another advantage which cannot be achieved by an algorithm 
using IMSIs as an input. As there is no "natural" link between the subscription and 
the authentication key, all keys have to be stored against some subscription specific 
data in a data bank of the AuC and have to be backed-up at a physically different 
location. As the authentication request involves the IMSI this would again be a 
natural choice. To protect the keys against unauthorised reading in the AuC they have 
to be stored in an enciphered form. The key (or keys) used for deciphering the 
subscriber authentication keys is clearly very sensitive. A compromise of such a key 
is in itself not as much a security breach as a compromise of the master key used to 
derive the authentication keys from subscription data. The attacker also needs a listing 
of the entries of the data bank. 

Similar things as before can be said about the choice of this algorithm. Assuming 
this to be the DEA in electronic code book mode [15], we can also see that the times 
required for providing a key for the authentication request are about the same for both 




238 



Klaus Vedder 



methods (assuming that access to the data bank causes no significant overhead). In 
both instances the DEA has to be executed twice. 

5.3 Pre-personalisation 

Pre-personalisation usually refers to assigning and loading a SIM with 
authentication key and IMSI and all other subscription relevant data. In general, no 
subscriber related information is required in the SIM for the access of a GSM service. 
A pre-personalised SIM may thus contain all information necessary for the GSM 
operational phase and be ready for use subject only to its 'release' in the HLR/AuC. 

Which of the methods described in section 5.2 is employed for the generation of 
the subscriber keys depends also on the administrative environment of the pre- 
personalisation. Deriving Ki from subscription data, which is known prior to the pre- 
personalisation of the SIM, allows the computation of Ki independently in the 
HLR/AuC and at pre-personalisation time. Ki need, therefore, not be transmitted 
between the two places. If Ki is a random number or depends partially on random 
data, then it may be generated either in the HLR/AuC or at the place of pre- 
personalisation. In this case Ki or the random data have to be transmitted in a secure 
way between the two entities. Both solutions have their advantages and disadvantages 
and a decision for one or the other should take all security and administrative 
boundary conditions into account. 

Abbreviations 

This section contains the abbreviations used in this paper together with a brief 
explanation. For a more elaborate description and the precise definition of all the 
terms the reader is referred to [5] and [6]. 

A3 Authentication algorithm A3; used for authenticating the subscriber 

A3 8 A single algorithm performing the functions of A3 and A8 

A5 Encryption algorithm A5; used for enciphering/deciphering data 

A8 Ciphering key generating algorithm A8 (cipher key generator); used to 

generate Kc 

AuC Authentication Centre; used to generate authentication data (thus 

containing individual subscriber keys Ki as well as A3 and A8) 

BSS Base Station System 

DECT Digital Enhanced Cordless Telecommunications (formerly: Digital 

European Cordless Telecommunications) 

ETS European Telecommunications Standard 

ETSI European Telecommunications Standards Institute 

HER Home Location Register; a register in the HPLMN of the subscriber 

where information related to the location and the subscription is stored 
HPLMN or HomePLMN: the network with which a subscriber is registered 
IC Integrated Circuit 




GSM: Security, Services, and the SIM 



239 



IMSI International Mobile Subscriber Identity; the identity which uniquely 

identifies the subscriber in all GSM networks, used for routing in GSM 
(not to be confused with the suhscriher's mobile telephone number) 

Kc Ciphering key; used in A5 to generate the key stream 

Ki Individual subscriber authentication key; used in A3 and A8 

LAI Location Area Identity; information indicating the location of a cell or a 

set of cells 

ME Mobile Equipment; the MS without the SIM 

MS Mobile Station; the equipment used to access GSM 

MSC Mobile Switching Centre 

PIN Personal Identification Number; used by the SIM for the verification of 

the identity of the user 

PLMN Public Lands Mobile Network; a network providing communication 

possibilities for mobile users 

PUK PIN Unblocking Key; used to unblock the GSM application which 

occurred as a result of three consecutive wrong PIN entries 
RAND RANDom number; used as a challenge in the authentication process 
SIM Subscriber Identity Module; the subscriber card containing security and 

other subscription as well as network related information 
SRES Signed RESponse; used to verify the identity of the SIM in the 

authentication process 

TMSI Temporary Mobile Subscriber Identity; the temporary identity of a SIM 

issued by a VLR to provide subscriber identity confidentiality 
VLR Visitor Location Register; the register where the user is (temporarily) 

registered while in a location controlled by this register 
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1 A Model for Secure Electronic Communication 

The typical business transaction requires up to three kinds of actors: Customers, 
service providers and banks. There may be several of each involved in a full 
transaction, e.g. an acquiring bank, the bank of the service provider, or seller, and an 
issuing bank, the bank of the customer, or buyer. This assumes that an infrastructure 
exists, which enables these three different entities to communicate together and 
recognise each other as legal entities with appropriate registered public keys. 

In order to handle Commerce electronically, more is required, however, and this 
documents aims at addressing some of the most important aspects which need to be 
taken into consideration. 

Our thoughts in this paper are based on the experience we have acquired through 
participation in a number of European pilot projects on Electronic Commerce, such as 
BOLERO; SEMPER, PROTONET, DYP and ELSME. 

Our model for Secure Electronic communication is characterised by the following: 

Key-related 

1. An ERA (Local Registration Authority) identifies and registers end-users, service 
providers and independent TTPs. 

2. A CA issues key-, or ID-certificates, which are entered into a Directory. 

3. A Directory Authority will make a list of all certificates and their status available in 
a database at all time. 

4. Blacklists are old-fashioned and will vanish. In stead, the Directory will calculate 
“instant certificates” which are communicated on request. 

Business-related 

1. Users make contracts with service providers (or other users on a bilateral basis). 
Gradually, some scenarios will be addressed by legislation. 

2. If several users subscribing to the same service provider communicates in a secure 
manner, the service provider may have role- or attribute-certificates issued, which 
state the legal profile of the users. 

3. The End-user may deal with a number of independent service providers. 

4. A service provider may or may not demand the End-user to use special keys for his 
services. 

5. A bank is just a special user if it accepts payment instructions. 

6. A bank is an independent TTP if it issues electronic cash. 

B. Preneel, V. Rijmen (Eds.): COSIC'97 Course, LNCS 1528, pp. 241-263, 1998. 

Springer-Verlag Berlin Heidelberg 1998 
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The smoothness of the so-called X.509 architecture, which should not be confused 
with an X.509 certificate, which in turn should not be confused with the syntax, - 
which (accidentally) was chosen for its description, ASN.l - relies entirely on the 
effectiveness of the Directory of all the users of the system. In fact, neither was 
designed for electronic commerce, but rather secure access control to databases. 

The Directory(ies) could be the responsibility of the Certification Authority(ies) 
and maintained by some physical center operated by the CA or managed by an 
independent third party, which have to establish a business relation with the CA. 



2 Threats and Legal Aspects 

One traditional approach to security is to determine the assets of the system and 
then consider the threats. Equally important, in fact, in most cases of electronic 
commerce, much more important, is the legal framework for the commerce. A digital 
signature does not per se have any legal effect, although this may change in the future 
as we see more and more legislation on electronic communication. But at least for the 
time being, there must be a contractual relationship of some kind, or the risk by not 
having one must be considered sufficiently small. This is the same pattern as we see 
with ordinary (e.g. non-electronic) commerce: ordering a book over the telephone by 
quoting a credit card number is commonly used, because the threats are relatively 
limited: The book has to be sent to the address of the person who wants the book. Of 
course if the book is very expensive, this may not be enough, and further security 
measures, such as first signing a contract, are taken. 

As e.g. electronic commerce covers everything from purchasing information which 
is worth a few cents to electronic bills of lading worth 100.000 $. (For more on this, 
see [9]), the threat pattern varies tremendously depending on the application. This is 
one reason for the diversity in the requirements for TTP-services. 

Anyway to secure communication is always a question of introducing the right 
security services: Security services must be provided which match the identified 
threats. 



3 Security Services 

A security service describes a natural user requirement. As an example, consider 
the four non-repudiation services, which may be required to complete the transaction 
of mailing a letter and receiving and acknowledgement. 
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Roles in applied KM Model 



Non-repudiation, or proof of, 

Origin or Receipt, (End-users) 

Submission or Delivery. (Require Independent TTPs) 

The terminology origin and receipt is course clear: It simply means that a digital 
signature is added by either the transmitter or the receiver to one particular message, 
which can be identified, in such a way that they cannot deny having created or 
received that particular message. Submission and delivery are the services required to 
send a registered letter. Non-repudiation of receipt and origin are the non-repudiation 
services in e.g. EDIT ACT (See [5]). 

Other traditional security services are message integrity, message authentication 
and confidentiality. Notice that non-repudiation related to a particular message 
content Implies the use of message integrity. 
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It is a common misunderstanding, though, in particular among more technically 
inclined people, that digital signatures provide non-repudiation. The correction 
assertion is that digital signatures are necessary to provide non-repudiation, but 
certainly not sufficient. In the first place, a digital signature may not have any legal 
value per se, as mentioned above, and the real effect of using it may be nothing more 
than message origin authentication, which does not involve any third party as 
arbitrator. 

In any case, these are some of the most important security services required in 
open systems. However as mentioned earlier, in the TEDIS report, entitled "Security 
in Open Environments" ([4]), a number of new security services, some with origin in 
the cryptographic world are introduced to meet new business requirements, such as 
“Claim of Ownership” and “Fair Exchange of Values”. Typically, they are all 
extremely well suited for implementations based on smartcards, and some of them 
cannot be realised without the involvement of TTP’s, either actively or passively. 



4 Trusted Third Parties 

Open electronic commerce is thus apparently unthinkable without the involvement 
of what with a common denominator are called Trusted Third Parties (see [16]. We 
will now address this in greater detail. We follow our recent paper [17] very closely, 
but going much more into details on the issues. 



4.1 Various Roles 

The most obvious need for Trusted Third Parties in data security has already been 
explained. We would now like to expand on this and discuss a number of other 
applications. The role of a TTP is related to one of the following (for more on this, 
see [8] and [13]). 

• Support services 

• Independent services 

Support services indicate that the TTP is there to support the user, or entity, to 
make use of security services. This includes registration and certification, service 
messages related to key management, and possibly even key generation, directory 
services, and more. 

Independent services cover the need for independent third parties to offer special 
services, be it to witness certain business acts, to certify authorisation and issue so- 
called user attributes, or whichever. As examples of this, we mention 

• Independent Time Stamping of documents and signatures 

• Legal attributes of entities 

• Access attributes 

• Archiving and registration (documents, ownership, etc.) 
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• Witness services (typically notary functions) 

• (Key Generation) 

A recent INFOSEC study based on interviews discusses various business 
requirements for trusted third parties (12]). See also the Green Paper ([6]). 



4.2 TTP Support Services 

For completeness we include 

4.2.1 Basic Terminology 

Attributes: Data which characterises an entity’s commitments and executive rights. 
In particular, these form the legal framework for the legal effect of a digital signature 
in a particular application. 

Certificate: A set of data consisting of entity credentials together with the digital 
signature on these credentials calculated by the secret key of the CA-public key pair 
associated with the domain. The certificate is used to provide the entity’s credentials 
and to guarantee their authenticity. 

Certification Authority (CA): There is only one CA within a security domain, and 
the security domain is characterised by the fact that all users of that domain are 
certified with one secret key, of the certification key pair, under the control of the CA. 

Certification-path: If several CA’s are involved to establish a link, one speaks of a 
certification-path. However, certification paths were never meant for handling 
electronic commerce, and should be avoided, as we shall see, for non-repudiation 
services. 

Credentials: A set of data items assigned to each entity, including a public key and 
used to identify that entity. 

Directory Authority (DA or DIR): Certificates, valid, revoked, on hold, etc. Are 
made available in a directory by the DA. Technically and/or physically, there may be 
no difference between the CA and the DA. 

Domain: A group of entities (e.g. end-users, various TTP’s as service providers) 
who may communicate together in a secure manner by relying on some particular 
trusted party, the 

(Local) Registration Authority((L)RA): The (physical) registration is handled by 
the (L)RA on behalf of the CA. 

Inter-domains: This domain may appear as a subdomain of a domain which 
encompasses a number of such subdomains, thus creating an inter-domain relation. 
The CA of the larger domain then has the CA of the subdomains as its end-users. 
Independently of this there may be a number of service providers and/or service 
applications. 

4.2.2 A Model for Key Management 

Key Management deals with all aspects of a key life time, i.e. the generation, 
protection, storing, distribution, certification, verification, revocation and deletion of 
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cryptographic keys in an open and secure information system (See [14]). As we have 
seen, a generic model defines five distinctively different logical roles which are 
relevant to the individual end-user in order for him to realise all kinds of secure 
electronic communication, but key management is deal with through the LRA’s, CA’s 
and DA’s. 

The model deals with the key management which addresses the primary keys: The 
user keys, and does not describe e.g. the key management required to build a secured 
database of keys. With this in mind, the following roles are required. 

Registration and Revocation 

• Certification Authority (CA) 

• Local Registration Authority (LRA) 

Directory 

• Directory Service Agent(s) (DSA) 

Service providers 

• Trusted Third Parties as special service providers 

• Other Service Providers 

End-users 

• Individuals, devices, etc., but typically representing a legal, or real, person. 

As mentioned earlier, common to all variations of this model is the fact that the 
users each have their own key pair(s), that the public key is registered and - typically, 
although not entirely - the CA issues certificates on these users and their public keys, 
which are then entered into a Directory under the responsibility of the DSA. 

4.2.3 Required Functionality 

The purpose of the CA’s and the LRA’s is only to register entities with their public 
keys and to maintain this information at all times. Information on registered entities, 
i.e. TTP service providers and End-users is made available in a Directory, which 
earlier was anticipated in the most advanced models to be a distributed X.500 
Directory. However, it seems natural to use Internet communication for accessing the 
Directory as well, and this will be the dominating solution. The dominating protocol 
seems to be LDAB. In any case, this Directory will as a minimum contain the 
information supplied by the CA’s and possibly other TTP’s registered by the CA’s. If 
so, the TTP may supply information related to the service it provides. 

The CA is connected by means of secured communication to the LRA’s, through 
which any user may register. A registration is acknowledged by a certificate issued by 
the CA at the request of some LRA. Finally, a number of additional TTP’s may 
register as well as providers of special services, examples of which are given below. 

If public keys are used, the LRA-public keys are typically only registered at the 
CA, and no certificates are issued on LRA’s, although this could be an option as well. 
Each CA may register a number of LRA’s. Registration typically requires physical 
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identification, for which reason the number of LRA’s can be relatively large in many 
systems in order to register all the users in a secure way. 

An End-user registers at an ERA of his own choice, typically the one closest to his 
premises. He is identified in the system by his credentials. This may involve manual 
procedures, which are specified elsewhere, and is the responsibility of a so-called 
Local Security Officer (LSO) at the LRA, or it may be handled purely electronically 
for low risk electronic commerce. The registered information is passed on to the CA 
in a secured message. 

The user furthermore registers a public key, of which the corresponding private 
key is known only to the entity, at least in the case of signature keys. In this process, 
it is usually required that the user demonstrates that he knows the corresponding 
private key. The CA verifies that this particular key has not been registered 
previously, if the LRA or the CA is not involved in the key generation. The CA then 
issues a certificate, typically with a certain validity period, which is returned to the 
user. 

The CA may update certificates or issue revocation certificates, if the public key is 
revoked. Each certificate has a unique reference number, and a status: regular or 
revoked. In particular, if a certificate is updated or revoked, its reference number is 
not changed. 

Any entity may extract information from the Directory by means of a Directory 
User Agent, a software package which communicates with one or several DSA’s. 
This communication, if based on X.500, is typically secured by non-repudiation 
based on digital signatures following the X.511 standard as far as communication 
from the DUA to the DSA. Again, Internet offers an attractive alternative. 

In any case, the main reason for a Directory, or Repository, is that a certificate 
only proves that the entity has been registered according to described procedures. 
Any entity may then through the Directory enquire about the present status of any 
certificate. The response must be secured to guarantee the inquiring entity that the 
answer is up-to-date. It is up to the entity to choose the criteria - and thus assume the 
risk - for how frequently to make a query to the Directory to ensure changes to the 
certificate status are not ignored. 



5 The Phases of a User- Key 

In order to design and specify a versatile CA, it is necessary to analyse the various 
phases of a User Public Key Pair. It is therefore assumed in the following discussion 
that the system has been initialised, i.e., the entities LRA, CA and DA have been set- 
up and are supposed to be trusted to carry out the registration, certification and make 
this publicly available in a Directory (also known as functional trust) by the users. 
Since the main object to focus on is the user’s key, the description of the model will 
follow the life cycle of a key: 

initiation operation/function revocation 
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Registration at local 
registration authority 




Communication with 
directory during session 
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1. Set-up 

user registration, generation, certification and distribution of keys. 

2. Normal operation 

using the keys in various security services such authentication, generation and 
verification of signatures, encryption/decryption, etc. The same key pair should never 
be used for more than one type of protocol (e.g. digital signature, or user 
identification, or session key encryption). 

3. Revocation 

covers the situation where a user signs off, a key is compromised, replaced, etc. 

The key management model will he described according to these three phases. 



5.1 User Set-Up 

Purpose: The user provides his credentials and public key to an LRA and, after 
verification, obtains the certificate of his public key as well as CA’s public key in 
some authenticated manner. 

For simplicity, we will only address keys used for signature generation and 
verification in the following. 

5.1.1 Key Generation 

5. 1.1.1 User generated key pair 

If the user has the ability to generate his own keys, this method provides some 
advantages, namely that no other person at any time has had potential access to the 
use of the private key. 

Although it seems preferable to build systems where the user is responsible for his 
own key generation, this does not necessarily mean that the keys are generated in his 
own environment, nor is it always preferable that he has an influence on the key 
generation. The weakness of user-provided keys is that we have no way of verifying 
that they were constructed in a secure (e.g. sufficiently randomly) way. 

In any case the key generation should always be carried out by an entity 
independent of the CA, or by a certified separate device if under the hospices of the 
CA. 

5. 1.1.2 TTP generated key pair 

The user sends a request to a TTP which offers key generation, and receives in 
return the generated public-secret key pair from TTP. This solution will implicitly 
require the use of chipcards for proper protection of the private key, or similar. One 
advantage of this approach is that this could be implemented in such a way that the 
user is unable to read his own key. 
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5. 1.1. 3 Secure Key Generation 

As far as public key schemes are concerned, two of the most important factors in 
secure key generation are 

1 . Generation of a sufficiently large random seed 

2. Generation of sufficiently random keys based on this seed. 

For instance most RSA key generation programs are of suspiciously low quality. 
One of the typical misconceptions is to create “strong” primes, the other to require 
that they are not of the same bit length. 

The trouble with “strong” primes is that the only way we can construct a prime p 
such that at the same time p-\ and p+\ contains a large prime divisor r and s 
respectively, is to invoke the Chinese Remainder Theorem. This construction is only 
possible if rs < p, which is not the case “in nature” at all. Secondly, most programs 
choose r and s to be of the same key length, which is even more artificial. 

The right approach, at least if the prime to be constructed is of length say 350 bits 
or more, is either to choose completely randomly, or to ensure that p-\ has a large 
prime factor. The are effective and secure algorithms around to construct either 
probabilistic or deterministic primes with these properties. 

The argument for choosing the RSA primes p and q to be of different length 
seems to be that this ensures that they are not to close to each other, in which case the 
obvious attack would be to calculate the square root of the product and then test all 
primes in that neighbourhood. 

However, if one prime is a dwarf compared to the other (i.e. 16 bits smaller), some 
of the factorisation algorithms applied to the modulus will be much faster. It is thus 
much better to request that the chosen primes, if of the same length, differs in the 
most significant 8 bits, say. 

5.1.2 Registration 

5. 1.2.1 User registration 

The User submits his credentials and public-key to the LRA. The credentials and 
the public-key may be transmitted electronically. The authenticity must be provided 
by additional means, e.g., the communication of a hash value using registered mail or 
personal appearance at the LRA. 

The User must prove that he knows the corresponding private key, e.g. by signing 
a request for certification (self-certification). 

The LRA validates user’s credentials, adds possibly some further information and 
the key, edits to a standard format and forwards this to CA for certification. 

5.1.3 Certification of User’s Public Key 

The CA generates the certificate on the user credentials (including the public key) 
based on a request from the LRA and possibly some validating data from the LRA, 
after having verified that the public key of the user has not been registered by any 
other user in the system. 
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5.1.4 Registration at DIR 

The CA sends the user’s credentials, public key and certificate to the DIR for 
publication. After verifying the certificate, DIR generates a user record and adds the 
credentials, public key and certificate to the directory. DIR then sends an 
authenticated acknowledgement to CA. 

5.1.5 Return of Certificate 

The CA sends the certificate to the user either directly or indirectly through the 
LRA, which then forwards this. In either way, it is furthermore of course imperative 
that the public key of the CA is communicated to the user in an authenticated manner. 
It is a good idea to have some means of verifying that this was received by the legal 
person responsible for the initialisation of the registration, before the certificate is 
released for general use by the Directory. 



5.2 Normal Operation 

Requirements: The user must be able to acquire other users’ public keys and 
certificates, and their current status. Updates and replacements of certificates must 
take place in a secure manner, with a guaranteed maximal delayed time period. 

In some systems there is moreover a requirement for forwarding blacklists to the 
various user. However, this approach is old-fashioned and dates back to the time of 
credit cards. 

It will be more and more common to see systems where it is the user’s 
responsibility to inquire at the DIR, or the CA, about the status of a certificate, rather 
than receiving blacklists, which are difficult to administrate. 

5.2.1 Public Key Request 

The User sends a request to the DIR to obtain e.g. another user’s public -key and/or 
certificate. The DIR must return the required information in an authenticated way. 

5.2.2 Certificates Validation 

A User may request a CA or a DIR to validate a certificate. The validation data 
should be sent to user in an authenticated way. If the certificate has been replaced 
with a revocation certificate (see below), the requesting entity is informed of this. 

5.2.3 Certificate Update 

The User forwards an authenticated request for updating of his certificate. This 
only implies an extension of the validity period of the valid certificate. The certificate 
is updated without revoking the old certificate. 

5.2.4 Certificate Renewal 

The user asks CA to renew the certificate of his public key. Both request and the 
new certificate content should be delivered in an authenticated way, possibly based 
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on the existing certificate. The request may have to go through the LRA. This 
procedure is chosen if some data in the certificate, such as an address, or similar, is 
changed. The CA will then first issue a revocation certificate to replace the old 
certificate, possibly with an indication of the reason for the revocation. 

5.2.5 Public Key and Certificate Replacement 

The user requests the CA (or LRA) to replace his current public key and, 
consequently, certificate as well. The CA (or LRA) verifies the authenticity of this 
request, enters the user’s old key and certificate on the revocation list, or issues a 
revocation certificate , issues a new certificate and delivers the new key and 
certificate in an authenticated way to the user. 

In many systems, there is no differentiation between renewal and replacement. 

5.2.6 Inter Domain Certification 

Inter domain certification means the exchange of certification information between 
users with different CAs (and LRA’s, DIR’s, TTP’s), e.g., CAl and CA2. CAl and 
CA2 must exchange each others public key and issue certificates on each other. 
Another possibility is to introduce a new security domain with a new CA and the 
different existing CA’s as users. However, some care is required, as it may impede 
the procedures for status inquiry on certificates of other domains. 

5.2.6. 1 Direct access to other DIR 

If a user in domain of CAl has CA2’s public key, he can directly access DIR2 to 
obtain public keys and certificates of users in domain CA2. If distributed directories 
are used, the same directory may be used by several CA’s. 

5. 2.6. 2 Interdomain access via CA 

A user in the domain of CAl but without access to other CA’s public key, may 
request CAl for the certification of users in other domains. CAl may then access 
DIR2 to obtain the required data, verify the authenticity, sign the data with CAl’s 
private key, and then return this to the user. 



5.3 Revocation 

The CA is responsible for the status of a certificate (and the related keys) and made 
declare this to be revoked before the expiration date. Reasons for revocation include 

• Compromise of the User’s private key; 

• User requests to change his credentials or cancel his registration; 

• The User’s registered identity is found to be false; 
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Requirements: 

Legitimate users should be able to confirm the invalidity of the revoked certificate; 
that is, such certificates and the related keys should be put in DIR together with CA’s 
certificates of revocation; 

The owner of the revoked certificate should be informed. 

5.3.1 Initiation 

53.1.1 Compromise of private key 

The User informs the CA (either directly or via LRA) in an authenticated way that 
the key has been compromised. The authenticity could be provided by additional 
means, e.g., using registered mail or personal appearance, or it could be by means of 
the key even though it has been compromised. Anybody else than the registered user 
with access to his key would certainly not revoke it! 

5. 3. 1.2 Cancellation or change of registered identity 

The User sends a revocation request to the CA (either directly or via LRA) in an 
authenticated way. The authenticity can be based on his signature as the user’s key is 
still authentic in this case. 

5.5. 7.5 CA revocation 

In certain cases, CA can revoke user’s certificates before user being informed. The 
procedures for this would have to specified in a contract. 

5.3.2 Generation 

Upon receiving the User’s request or at its own initiative, the CA generates a 
special message to achieve the goal of revocation. It should contain user’s identity, 
public-key with its certificate, time of revocation and CA’s signature. Several 
possibilities are available, e.g. 

i) Signed information about the change of the status, which is then added to the 
User record in the DIR. 

ii) The generation of a so-called revocation certificate, which is the content of the 
revoked certificate, together with its new status, signed by the CA. In particular, the 
revocation certificate has the same certificate reference number as the original 
certificate. The reason for this is that typically, the revocation only implies that new 
signatures should be verified. But there is still a need to verify signatures generated 
before the certificate was revoked. The revocation certificate replaces the original 
certificate. 

5.3.3 Confirmation of Revocation 

5.3.3. 1 CA confirms the revocation 

CA sends the revocation certificate, or the signed revocation, to user (either 
directly or via LRA) in an authenticated way. 
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5.33.2 Registration of revocation certificate in DIR 
CA sends the revocation certificate, or the revocation, to DIR for publication in an 
authenticated way. After validating, DIR sends an acknowledgment to the CA. 



5.4 Exceptional Situations 

5.4.1 Compromise of CA’s Private Key 

If CA’s private key is compromised, the certificates generated by CA can no 
longer be expected to be authentic. In this case, all the certificates and other security 
links around the CA should be reset. However, users can still use their public key if 
mutual trust has been established between them by exchange of public keys before 
CA was being compromised. It is important to realise that the compromise of CA’s 
private key does not imply the compromise of user’s private keys. 

5.4.2 Back-Up Procedures 

In view of the remarks above, it is imperative to have amble back-up of the CA 
public key pair. In view of the importance of these keys, the best solution is to use a 
secret sharing model with parameters n, the number of shares, and k, the number of 
shares required to regenerate the secret key inside a cryptographic facility. 



6 System Architecture 

In major systems, there will be many CA’s, the security domains of which are 
disjoint. Nevertheless, there are techniques by which entities in different security 
domains may communicate, the so-called certification paths. 

In order to handle this the CA needs an operational Key Centre (KC). 

Moreover, a number of (local) Registration Authorities (RA) serving the domain 
will enable the registration and certification of entities. The main reason for this is 
that an entity must be identified by the system, perhaps even physically. This 
registration is more secure if it takes place locally. 

The centres must be served by Security Officers, CSO’s (Central Security Officers) 
at the KC and LSO’s (Local Security Officers) at the LRA’s. Each LRA organisation 
will need to register a LSO at the CA. This is handled by the CSO’s at the CA. There 
exists only one copy of the secret certification key S, except for protected backup 
copies, at the KC. 
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Revocation of a key, 
e.g. if it is compromised 
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6.1 Security Officers 

The formal registration of LRAs is carried out by a Certification Authority (CA) 
under the management of the CSO’s (Central Security Officers). The registration of 
users is carried out by the LRAs under the management of the LSO’s (Local Security 
Officers). 

The CSO’s are uniquely identified by means of at least access control. 

Their functions will typically include 

i) To identify and register the LSO’s. 

ii) To identify, register and initialise hardware and software 

iii) To initiate the generation of domain key pairs. 

iv) To back up the secret domain key. 

v) To serve as LSO if the CA is an LRA as well 
The functions of the LSO’s are 

i) To identify and register entities. 

ii) To provide to the CA the information necessary to issue of 
certificates. 

iii) To initiate revocation of a user. 
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6.1.1 Service Primitives 

The services to be provided in a key management system based on public key tech- 
niques include the following: 

Enrolment primitives: 

i) Registration 

ii) Certification 

iii) Key generation, back-up and storage 

Distribution primitives: 

iv) Key distribution 

v) Key authentication/verification 

Maintenance primitives: 

vi) Key activation 

vii) Key replacement 

viii) Key deletion 

ix) Revocation (formerly BlacklistsAVhitelists) 



6.2 Specification of CA/RA Data Flow and Processes 



6.2.1 Scope 

In this section we will describe the user functions which are required in the largest 
systems from our experience. On the other hand, there may be systems that require 
additional functionality. 

The list of functions is determined from a specification of the message flow 
between the CA and all other classes of entities, and the functionality which in 
addition must be available to handle the CA operations. 



6.2.2 Internal CA Operations 

Key generation of the CA keys 
Audit trail functions 



All calls of other functions should probably be logged. 
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Generate Certificate/Revocation Certificate 

Certificates will either be generated on incoming credential information from an 
LRA, on electronic form, possibly supplied by the public key if generated at the CA, 
or on already existing information in the X.500 database. In particular, the CA will 
not necessarily maintain its own database, but rely on the X.500 directory. 

To summarise, four distinct certificate operations can be requested: 

Generate is used initially, when a new user wants to have a certificate generated 
and added to the directory. LRA interaction is necessary for verification of 
credentials. 

Update is used for minor changes to the certificate, e.g. change of the expiration 
date (which does not require LRA interaction). The existing certificate is replaced by 
the updated certificate using the same reference number, i.e. managed by the CA. 

Renew is used when major changes, such as key replacement, are made to the 
certificate (RA verification/interaction is required). The existing certificate is replaced 
by a revocation certificate, and a new certificate is generated and added to the 
directory. 

Revoke is used when use of the certificate is to be cancelled before it expires. This 
can be the case if a person leaves his/her repository, if the key is compromised etc. To 
minimise the time delay, LRA interaction is not used when revoking a certificate. The 
existing certificate is replaced by the revocation certificate. 

Communication with End Users: 

GetUpdateRequest 

Get a request to update a certificate (see explanation above). 

GetRevokeRequest 

Get a request to revoke a certificate (see explanation above). 

SendCertificate 

Return a new or updated certificate (active or revoked) to a user. 

GetCertificateStatusRequest 

Get a request for the status of a given certificate. 

SendCertificateStatus 

Send the status of a given certificate. This requires non-repudiation. 

Communication with LRA 

GetValidCredentials 

Receive user’s credentials and LRA’s validation, as a request to 
generate a certificate. Before a certificate is generated, CA must verify 
if this particular public key has been registered before. This implies that 
the CA must be able to compare against all previously registered public 
keys 
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SendValidationResult 

Send a instruction to LRA as how to proceed. This will take the 
following forms: 

1 . Credential information on user invalid 

2. Public Key Format not acceptable 

3. Public Key not acceptable 

The LRA may then retransmit new information by means of Send Valid 
Credentials. As mentioned above, this is a grave situation, which may 
require delicate consideration. 

SendCertificate 

Return a certificate to LRA. This transmission should be authenticated. 
If CA generates the End-user’s keys transmission should be confidential 
too and handled by special procedures. 

GetRenewalRequest 

Get request to renew an EU’s certificate before expiration. 

Communication with DIR 

All communication between the Directory (Service Agent) and the CA 
(User Agent) must be authenticated, at least in the full commercial system. 

AddNewCertificate 

Add a new EU’s certificate (active or revoked) to the directory. 
ReplaceCertificate 

Replace an existing certificate with a new (e.g. updated or revocation 
certificate). Note that renewal requires that the old certificate is replaced 
by a revocation certificate. 

GetCertificate 

Retrieve a given certificate from the directory. 

SearchCerificate 

Search the directory for certificates (or certificate id’s) matching given 
criteria. 

DeleteCertificate 

Delete a user with a given id from directory. This will only be allowed 
when all certificates have expired and have no further legal value. 

Communication between End-users and LRA 

Forward credentials 

This could be an electronic message from the user containing the 
information he can provide, including his public key. 
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GetRevokeRequest 

Get a request to revoke a certificate (see explanation above). The LRA 
would subsequently forward the request to the CA. 



7 Examples 

In the following, three different realisations of the architecture described above 
will be given. In our opinion these cover the range, within which open so-called 
X.509 architectures are being build in Europe. 

Cryptomathic plays a central role in the specification, design and implementation 
of all of these, as well as several others. 



7.1 The BOLERO/FAST Model 

The model is named from the largest ongoing implementation of the X.509 
architecture in Europe, the INFOSEC project BOLERO. The purpose of the project is 
to replace paper versions of Bills of Lading by electronic versions. 

The current ownership is registered at special service providers, so-called 
Registries, based on communication with the Users secured by digital signatures. The 
project was described in Banking Technology, Oct. 1994. 

The LRA-CA-DIR set-up is legally - and logically - independent of the business 
application, which is electronic trade of Bills of Lading. The set-up of this follows the 
general model developed above, with a distributed X.500 database. 

It is anticipated that other TTP’s made be established in the system as service 
providers. 

At this stage, only a very primitive LRA and CA are being provided in the pilot, 
but the intention is to go for the solution described above. 



7.2 The SEMPER Model 

This model, which is the most general, is precisely the model we have described 
here. User will be issued with Key Certificates, and set up their own relations with the 
service providers. The liability of the CA is restricted to perform correct identification 
according to the announced policy, and to make information on revocation available 
within a certain time period. This liability is thus objective with an upper limit on any 
indemnification, independent on any loss in a transaction. 



8 TTP Independent Services 

The meaning of trust should be reiterated here: Any open system requires some 
trusted party to carry out a number of operations. It may be purely functional, as in 




260 



Peter Landrock 



the X.509 architecture, where the CA is trusted with registering responsibilities only. 
Likewise it may be desirable to let the CA be responsible for some certification of the 
applied soft- and/or hardware. But again this only implies what we have called a 
functional trust, nothing more. 

In other systems based on conventional methods, a user has to trust the key 
distribution centre with some secret key or perhaps even to be assigned a secret key 
generated by a central key generation facility. If some authority in principle has or 
has had access to the user’s keys, we speak of unconditional trust, as mentioned 
earlier. 

For notary TTPs, this taxonomy may not be so appropriate. However, it would be 
reasonable to call any TTP, which needs to be consulted in order to provide evidence 
an unconditional trusted third party. The point we try to make is that by using 
cryptographic methods, we can reduce the need for UTTPs considerably. 

8.1.1 Time Stamping 

One important purpose of independent time stamping is the following: If the 
certificate of a public key is cancelled on the grounds that the corresponding secret 
key has been compromised, a previously calculated digital signature by the said secret 
key would retain its legal value, if an independent time stamping had taken place 
before the cancellation of the certificate. 

The user simply collects any number of digital signatures over a period of time 
(one day, one month,...) and sends it off to the TTP(TS) for time stamping. The 
TTP(TS) adds the TS and a digital signature and returns the message. 

8.1.2 Legal and Access Attributes 

As user related attributed may change quite often, it seems a better idea to define 
and enhance them in special certificates. Indeed, Public Key Certificates should not 
be changed to often, as this creates a lot of administration overhead. Indeed, if any 
parameter in a public key certificate is altered, the certificate is no longer valid. 

As for legal attributes, this any way is very much in accordance with what is done 
in the paper world. Each country has a register of companies and the executive rights 
of various persons working for the company. This is exactly the situation we want in 
the electronic world as well. 

Likewise access control to e.g. databases can be handled on the basis of access 
attributes created and digitally signed by appropriate third parties. 

Finally, a service provider may make his customers attribute profiles in the system 
he offers available in attribute certificates either issued by himself or by a contracting 
CA. 

8.1.3 Archiving and Document Registration 

As explained, claim of origin presumes the existence of a Trusted Third Party. 
Other examples of such parties exists as well. For instance, securities (bonds and 
stocks) are mostly registered electronically, only, in Denmark, in as far as negotiable 
documents on the stock exchange are concerned. The ownership of the documents is 
simply registered at all time by the Danish Securities Centre, without the use of 
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cryptographic methods, but ensuring the integrity of the whole system by access 
control and very strict business procedures. 

8.1.4 Witness Services 

In certain countries there are great traditions for involving third parties in a number 
of transactions, so-called notaries. In others, this is hardly used at all. Naturally, as we 
proceed towards purely electronic handling of a number of business cases, we can 
replace the traditional notary function with a similar purely electronic function, if the 
laws of the country will permit that. For more on this, we refer to [12]. 



9 Conclusion 

We have explained the difference between supporting TTPs and TTPs offering 
independent services. 

It is important to build the system in such a way that Registration, Certification and 
Directory Authorities will not be liable for failure of business transactions. They 
should only be liable for 



Correct registration (following they procedures) 

Making Revocation information available 

There are a number of possibilities: 

They could be licensed, certified or regulated, and users could purchase insurance 
on electronic commerce 

TTP’s and Service Providers selling an independent service are commercial 
enterprises, which does not require other legal action than a contract with its 
customers. 

A major question is to what degree we need to address TTPs in legislation. We see 
the first attempts in Europe to address this already (Germany, Denmark,...), as we 
have seen it in USA (e.g. Utah). 
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Abstract. In this paper we describe mechanisms for the management of 
secret keys, used in the securization of financial applications. The mecha- 
nisms Dynamic Key Handling and Reversed Dynamic Key Handling can 
be seen as particular methods to diversify keys in time, compatible with 
the present diversification by terminal and/or electronic purse. 



1 Introduction 

In this paper we describe two mechanisms that are used for handling secret keys 
used in the cryptographic protection of financial applications. 

The first mechanism is the so-called Dynamic Key Handling (DKH). Basi- 
cally, DKH is a method to synchronize cryptographic keys between the secure 
communication module (SCM) of an ATM, an EFT-POS or a Proton merchant 
terminal on one hand and the Host Security Module (HSM) of the central system 
on the other. The keys are used for several cryptographic services, related to the 
protection of the messages exchanged between the terminal and the Host. The 
most important of those services are the generation and verification of message 
authentication codes (MAC) and the encipherment of PINs. 

The second mechanism is called Reversed Dynamic Key Handling (RDKH) . 
RDKH is a method used to realize the regular update of cryptographic keys in the 
Proton electronic purses and the secure application modules (SAM) of Proton 
Merchant terminals without sacrificing full purse-terminal interoperability. The 
keys are used to secure the off-line purchase transactions between Proton purses 
and Proton merchant terminals. Banksys has patented the Reversed Dynamic 
Key Handling mechanism in Belgium and an International patent is pending. 

2 Preliminaries 

The communication and application security of the majority of financial applica- 
tions today is based on the security services of message and entity authentication 
and encipherment, realized by using secret-key cryptographic functions. In gen- 
eral, the secret keys are protected by storing them in ’’tamper-resistant” devices 
(e.g., Smart Cards), capable of executing the necessary cryptographic functions. 



B. Preneel, V. Rijmen (Eds.): COSIC’97 Course, LNCS 1528, pp. 264-|^^ 1998. 
(c) Springer- Verlag Berlin Heidelberg 1998 
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The security of the system therefore relies on the tamper resistance of the secu- 
rity modules that hold the secret keys. 

However, provably tamper-resistant modules do not exist and a possible key 
disclosure cannot be excluded. Therefore, it is wise to build systems in such a way 
that the consequences of the disclosure of key material are as small as possible 
and that a recovery to a secure situation is facilitated. The basic mechanism to 
obtain this is key diversification: 

Hierarchic Key Derivation: terminal security modules and electronic purses 
are loaded with keys that are derived from master keys by means of one- 
way functions, diversified with purse or terminal dependent parameters. If a 
derived key is compromised, the secrecy of the corresponding master key is 
protected by the one-way property of the derivation function. 

Session Keys: keys that are present in the terminal security modules and/or 
purses are not used directly for the calculation of authentication codes or for 
encipherment. Unique session keys are used instead. These session keys are 
also derived using a one-way function. Session key repetitions are prevented 
by the use of dynamic key handling and diversification using terminal and/or 
purse transaction numbers. 

Regular Updates: Specific keys in the terminals and purses are updated reg- 
ularly when they come online with the Purse Provider’s Host/HSM. The 
necessity for compatibility with the key hierarchy has resulted in the Re- 
versed Derived Key Handling mechanism. 

The two mechanisms that are the subject of this paper, DKH and RDKH, can 
be seen as particular methods to diversify keys in time, compatible with the 
present diversification by component. 

3 Dynamic Key Handling 

The basic goal that underlies the application of the Dynamic Key Handling is 
the following: 

The cryptographic keys that are inside a terminal may not allow to 
derive keys that have been used in any previous communication ses- 
sions. 

DKH is in fact an implementation of the mechanism of Key Transformation 
as mentioned in ISO standard 1 1568-3 p. 

Every terminal secure communication module (SCM) has a unique identifier 
(IDscm) and is loaded initially with a unique seed key. To facilitate the key 
management at the HSM/Host side, they are derived from a single master key, 
stored inside the HSM. The derivation process has the following properties: 

— The derivation function is a one-way function based on triple-DES. 

— The derivation is parameterized by IDscm to assure uniqueness of seed keys. 
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Due to the one-way property of the derivation function, it is infeasible to derive 
the master key from any set of seed keys. Moreover, given any number of seed 
keys, corresponding to a set of terminals, it is infeasible to calculate a seed 
key of any other terminal. The HSM can at any time calculate the seed key 
corresponding to a terminal with a particular IDscm- 

The key inside a terminal evolves irreversibly according to a non-trivial pro- 
cedure. In the following subsections, we will describe and motivate the design of 
this procedure. 

3.1 Linear Key Derivation 

According to our basic goal, a cryptographic key that has been used by a terminal 
during a communication session with the Host/HSM must be deleted from the 
memory of the terminal SCM. Still, there must be key material available for 
future use. Moreover, the HSM must be able to derive the key used during a 
session. 

Conceptually the simplest mechanism to obtain this is the following: 

After nse of a key, it is replaced by a value obtained by performing a 
one-way transformation on the key. 

This is illustrated in Figured 

KeyO — > \ Key 1 — > \ Key 2 — Key 3 | — Key 4 — > \ Key 5 ■■■ 

Fig. 1. Key evolution according to a linear structure. 



With this solution, the workload of the terminal is one application of the 
one-way transformation per session. For the HSM we can choose between two 
possibilities: 

— The HSM can keep the most recently used key of every terminal in a table 
and use it to derive the next key with. 

— From the seed key (derived from master keys and IDscm) and the sequence 
number (e.g., communicated at the beginning of a session), the HSM can 
derive the used key by iterating the one-way transformation the appropriate 
number of times. 

In the first case a large table containing a key for every terminal has to be man- 
aged by the Host/HSM. This can be realized by storing the keys in enciphered 
form on the Host system but this gives rise to an important key management 
overhead. In the second case, the workload of the HSM grows to an unacceptable 
level as terminals in the field accumulate sessions. Therefore another approach 
has been chosen that allows the efficient derivation of keys in the HSM without 
the need for large key tables. 
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3.2 The Principle of Tree-Like Key Derivation 

A key can be derived into several other keys by applying the one-way transfor- 
mation for different values of a parameter. If for instance every key is derived 
into two other keys, the resulting diagram is a balanced binary tree: every node 
has two child nodes. An example of such a tree is depicted in Figure |3 It can 
be seen that a binary tree with depth d gives rise to 2^^ — I keys. The number 
of iterations of the one-way transformation to compute a key starting from the 
seed key (node 0) is called its path length and is determined by the depth of the 
node in the tree. Clearly, the maximum path length in a tree with depth d is 
d-1. 



KeyO — > \ Key 1 — ► [ Key 3 — Key 7 ] 

Key 8 

► ! Key 4 ] — ► ] Key 9 ^ 

► ] Key 1 0 ^ 

H Key 2 ^ Key 5 ^ Key 11 

> \ Key 12 

► ! Keys ^ Key 13 

Key 14 ] 

Fig. 2. Key derivation according to a tree structure. 



Example 7. In a balanced binary tree with about one million nodes, the maxi- 
mum path length is 19 and the mean path length is less than 16. For a linear 
key chain this is respectively 999,999 and 500,000. 

Each key can be derived into more than two keys. If this number is equal 
for all nodes (except those of maximum depth) the tree is called balanced. For a 
balanced tree of depth d in which every node has n child nodes, the number of 
nodes is given by (n'^ — l)/(n — 1). 

According to our central goal, a key must be deleted from the memory of 
the terminal SCM after the session in which it is used. This implies that before 
deletion, its child keys (if any) must be computed and stored in the terminal 
SCM. Hence, for the binary tree diagram every use of a key below depth d gives 
rise to the storage of 2 new keys. This implies that a table of keys must be stored, 
rather than a single key. The key table consists of a number of slots, each capable 
of storing one key. A slot containing a key is called occupied, otherwise it is free. 
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The total amount of slots needed depends strongly on the order in which 
the keys are used. If the keys in Figure |2| are used in the order 0, 1, 2, the 
maximum number of slots needed is 8. This situation occurs after the use of 
key 6, when keys 7 to 14 have to be stored. For a general balanced tree, this 
amounts to slots needed. Hence, for this order, the number of slots required 
is comparable to the total number of keys in the tree. 

By imposing another order, the number of slots required can be significantly 
reduced. Consider the following order in our binary tree example: 0, 1, 3, 7, 8, 4, 
9, 10, 2, 5, 11, 12, 6, 13, 14. The number of slots needed is only 4. The maximum 
number of keys have to be stored after the use of key 3, when the key table 
contains keys 2, 4, 7 and 8. For a binary tree of depth d the required number of 
slots is d; for a general balanced tree, this is {n — l)d + 1. This illustrates that 
using a limited number of slots and a limited depth, a balanced tree with a large 
number of keys can be generated. 

Key evolution can be depicted in a so-called key evolution diagram, with the 
table slots set out vertically and the key evolution set out horizontally. The use 
and destruction of a key is denoted by a dot, key derivation is indicated by 
arrows. Figure Ogives an example of a key evolution diagram for a balanced 
binary tree of depth 5. 




Fig. 3. Key evolution diagram with a binary tree structure. 



Balanced trees may be the easiest case to study, they are certainly not the 
optimum solution. In Figure El it can be seen that the 5-th slot is only occupied 
during a single cycle. In actual implementations it is preferable to make optimal 
use of the available resources. 

Example 2. Figure 0 contains a key evolution diagram in which the number 
of child keys of a key is equal to the number of available slots and which has 
maximum depth 5. This diagram requires only three slots, can generate 35 keys 
and has a mean path length smaller than that of the binary balanced tree of 
depth 5 containing only 31 keys. 

Real-world constraints for a DKH scheme are : 

— The number of required slots (SCM memory). 

— The mean path length of the used nodes (average HSM workload). 

— The total number of nodes (SCM potential life-time). 
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Fig. 4. Key evolution diagram with a non-binary tree structure. 



— The overhead (time and memory) of determining the position of a key in the 
key evolution diagram (SCM memory and workload). 



3.3 Banksys DKH 

In the key evolution as adopted by Banksys the position of a key in the key 
evolution diagram is indicated by its (unique) key tag. This key tag is used by 
the terminal to determine the keys that have to be derived after use of the key 
and by the HSM to derive the corresponding key from the seed key. 

The two parameters for the Banksys key evolution are : 

S: Number of slots, 

K-. Length of the key tag, expressed in bits. 



Properties of the One-Way (Derivation) Transformation The DKH One- 
Way transformation has the following properties: 

— It is a one-way transformation based on DES. It is infeasible to calculate the 
input given the output and the parameters. 

— It is parameterized by the position of the last 1-bit in the key tag to diversify 
the different child keys derived from the same key. 

— It is parameterized by the SCM identifier IDscm to make certain that two 
equal keys for different SCMs do not give rise to two equal child keys. 



Derivation of Keys After usage of a key, its derived keys (if any) are generated 
and stored in free slots. This includes the slot of the used key, that will be 
overwritten. Clearly, the number of derived keys from a key is upper bounded 
by the number of free slots available (say h) in the key table. Given the tag of a 
key, the tags of the derived keys are determined by the following procedure: 

— Determine the number of free slots h. This includes the slot that holds the 
current key, so we have 1 < h < S . 

— Locate the rightmost all-0 bit string (say of length t) in the key tag. We have 
Q<(.<K. 

— For i from 1 to £, do the following: construct a tag by replacing the all-0 bit 
string by a bit string with a single 1 on position i. Derive the corresponding 
key and store it in a free slot. Mark the slot as occupied. 
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If ^ = 0, i.e., if the tag ends in a 1, no keys are derived. The key used in the 
previous session is deleted from memory and its slot is marked as free. Clearly 
the number of keys that are derived after a session is min(ft,,t'). 

Example 3. Say K = 10. The possible tags derived from key with tag 1011100000 
are given by: 

1011110000 

1011101000 

1011100100 

1011100010 

1011100001 

If ft, = 3, only keys corresponding to the first 3 tags are generated and all 3 
free slots are filled. If ft = 7, two slots stay empty. 

It can be seen that if the tags are considered as binary coded unsigned inte- 
gers, the tag of a key is always higher than that of its parent key. 



Derivation of a Key in the HSM Given the key tag, the HSM is able to 
derive the corresponding key from the seed key. From the key tag derivation it 
follows that the parent of a key tag is formed by replacing the rightmost 1-bit 
by a 0-bit. This can be performed iteratively to arrive at the all-0 key tag of the 
seed key. The path length of a key, i.e., the number of iterations of the one-way 
transformation needed to calculate it, is equal to the Hamming weight (number 
of 1-bits) of the tag. 

Example 4- the parent key of key with tag 1011100010 has tag 1011100000. The 
complete path is given by: 

0000000000 

1000000000 

1010000000 

1011000000 

1011100000 

1011100010 

where every key is derived from the key with tag in the previous line. 



Determination of Successor Key Tag in the Terminal After usage of 
a key, the key of the following session must be determined. This is called the 
successor key. The basic principle governing the order of the keys is: 

The most recently derived key is used first. 

This implies that the use of a key is followed directly by the use of all its 
descendents. The most recently derived key is simply the key in the table with 
the lowest tag, since it can be shown: 

Property 1: The keys in the table have been generated in the reverse order of 
their tag values. 
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Proof, (by induction) 

Initial situation: 

The seed key with the all-0 tag is in the first slot. Since there is only one key in 
the table, the key with the lowest tag and the most recently derived key coincide. 

Induction step: 

Assume Property 1 applies for the current state of the key table. We will demon- 
strate that this is also the case for the successor state. 

Case 1: No keys are derived from the current key. 

The state transition simply consists of the deletion of the last key. Clearly, if 
Property 1 is valid for the current state, it is also valid for the successor state. 

Case 2: There are keys derived from the current key. 

The tags of the keys that are derived from the current key are obtained by 
replacing the rightmost all-0 bit string of the current key tag by 1000 . . . , 0100 . . . , 
etc. For these keys, it can be seen that the one with the lowest tag is generated 
last. It remains to be demonstrated that the tags of these keys are lower than 
the tags of all other keys in the table. 

Assume the table contains a key (say X) with a tag that is lower than at least 
one of the new tags. Since Property 1 applies for the current state, the tag of 
key X must necessarily be higher than the tag of the current key. These two 
constraints impose that the tag of X must be equal to the tag of the current 
key, with the exception of the rightmost all-0 bit string. This implies that key 
X would be a descendent of the current key, and therefore necessarily generated 
more recently. This contradicts the hypothesis that Property 1 applies for the 
current state. 



The key with an all-1 tag has no successor since it has no children and has 
the highest possible tag. 

This scheme can be implemented by storing the tags together with the keys 
in the table. After generation of the child keys (if any), the successor key is 
determined by selecting the one with the lowest tag. In practice, the redundancy 
in the different key tags is used to reduce the amount of memory needed for 
their storage. 



Example 5. lih = 3, the successor of key with tag 1011100000 has tag 1011100100. 
If ft- = 8, the successor of key with tag 1011100000 has tag 1011100001. 

In fact, the tag of the successor key can be easily constructed from that of 
the current key, without having to resort to the tags stored in the table. We have 

Property 2: The tag of the successor of a key with tag ending in a 1-bit is given 
by replacing the rightmost 0-bit and the trailing 1-bits of the current key by a 
1-bit and an equal number of trailing 0-bits. 
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Proof. : 

— The current key is the last descendent of a key X with tag given by replacing 
the rightmost all-1 bit string by a single 1 followed by an all-0 bit string. 

— Consider the key Y with the tag constructed by taking the tag of X and 
interchanging the rightmost 1-bit and the 0 before it. 

— Clearly key Y and X have the same parent key and were generated during 
the same step, Y just before X. Since the descendents of X are exhausted, 
Y is the most recent key in the table. 



Example 6. The successor of key with tag 1011100111 has tag 1011101000. 
1011100111 descends from 1011100100. Together with 1011100100, the keys with 
tags 

1011110000 

1011101000 

1011100010 

1011100001 

were generated. The last two have already been used before 1011100100, the first 
two are still available in the table. The most recently generated is the one with 
tag 1011101000. 

Property 2 can be used to reduce the amount of memory needed for the table. 
Next to the actual key values, only the tag of the current key must be stored 
and the order in which the keys were generated. 



3.4 Statistics 

The two parameters S and K determine the total number of keys M and the 
mean path length p. In this subsection we derive expressions for these quantities. 
We have: 

Property 3: The number of occupied key slots is given by the number of 0-bits 
before the rightmost 1-bit of the tag of the current key plus 1. 

Proof, (by induction) 

Initial situation: 

Consider the successor state of the initial state (in which the key table only 
contains the seed key.) The current key has a tag with a single 1 in position S 
(the lowest occurring tag in the table) and the total number of occupied slots 
is S. Clearly the number of 0-bits before the rightmost 1-bit of the tag of the 
current key is S' — 1, hence Property 3 holds. 

Induction step: 

Assume Property 3 applies for the current state of the key table. We will demon- 
strate that this is also the case for the successor state. 
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Case 1: No keys are derived from the current key. 

The state transition simply consists of the deletion of the last key. The key 
tag of the successor can be constructed by replacing the rightmost 01111... 
bitstring by 10000 .... The number of 0-bits before the rightmost 1-bit of the tag 
is diminished by 1 and so is the number of occupied slots. 

Case 2: There are keys derived from the current key. 

The keys that are derived from the current key are obtained by replacing the 
rightmost all-0 bit string by 1000..., 0100..., etc. The successor key of the 
current key is the one with the smallest tag. The additional number of 0-bits 
before the rightmost 1-bit of the successor key tag with respect to the current 
key tag is the number of newly generated keys minus one. This is equal to the 
additional number of occupied slots, hence Property 3 is preserved. 



The number of possible keys with path length w is given by 

^min(S' -I- w — 1, K)'^ 

This follows from the fact that the tags with Hamming weight w can be enu- 
merated with the positions of the 1-bits. These bits are confined to the first 
(S' -I- w — 1) positions of the tag. This can be seen as follows: 

— The number of 1-bits is w. 

— The number of 0-bits before the rightmost 1-bit is at most S — 1, since 
the number of occupied slots may not exceed S (Property 3). Hence the 
rightmost 1-bit must be in position S -I- w — 1 or lower. If the tag is shorter 
than (S -I- w — 1), obviously the 1-bits are confined to the K bits of the tag. 
Observe that for small Hamming weights this expression is independent of 
the size of the key tag K. 

The total number of keys M is given by summing over all path lengths: 




min(S' -I- w 
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Hence, the total number of keys is 




The mean path length p is given by taking the average for all possible keys: 

1 fmhi(S + 'w—l,K)\ 

p=M^[ w r 

w^O ^ / 

Tabled gives M and p for some typical values of K and S. 





A = 16 


A = 24 


A = 32 


s 


M 


P 


M 


P 


M 


P 


4 


2,517 


10.60 


12,951 


16.92 


41,449 


23.29 


5 


6,885 


10.33 


55,455 


16.85 


242,825 


23.46 


6 


14,893 


9.92 


190,051 


16.55 


1,149,017 


23.32 


7 


26,333 


9.47 


536,155 


16.12 


4,514,873 


23.00 


8 


39,203 


9.02 


1,271,626 


15.60 


15,033,173 


22.53 


9 


50,643 


8.63 


2,579,130 


15.04 


43,081,973 


22.00 


10 


58.651 


8.34 


4.540.386 


14.47 


1.076 10“ 


21.40 


11 


63.019 


8.14 


7.036.530 


13.92 


2.966 10“ 


20.77 


12 


64.839 


8.05 


9.740.686 


13.40 


4.624 10“ 


20.13 



Table 1. M and p for some typical values of S and k. 



3.5 Session Key Derivation and Usage 

The terminal uses the keys in its key table to : 

— secure PIN transmission by encipherment, 

— provide message authentication by generation of MAC, 

— provide application-level authentication codes. 

The keys that are in the key table are not used directly for these purposes, but 
are the input to a one-way function to derive the actual session keys. 

In order for the HSM to derive the current key of a terminal, it must know 
its tag. Since the Host/HSM does not keep track of the tags of all the termi- 
nals, the HSM can only use a key for the protection of a message towards the 
terminal if the terminal has already contacted the HSM and communicated its 
tag previously. 
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4 Reversed Dynamic Key Handling 

PROTON is a electronic purse scheme exploited (Belgium) and sold (abroad) 
by Banksys. The security of its architecture is to a large extent realised by the 
use of an elaborated scheme of differentiated cryptographic keys. 

Proton purchase transactions, i.e., transactions between Proton purses and 
merchant terminals are done off-line. There is no connection to the centralized 
Host system. A purchase transaction is secured by session keys that are derived 
from keys inside the purse and the secure application module (SAM) of the 
merchant terminal. For every purchase transaction a new session key is calculated 
by purse and SAM. This session key is determined by the pair of master keys 
(KMa and KMb) and a number of session-specific parameters. 

This is realized by a two-level hierarchical key structure whose detailed de- 
scription is out of the scope of this paper. The SAMs are subdivided in a number 
of families, each of which receives a different key derived from KMa. These ’’fam- 
ily keys” KDa are again derived by Purse ID to keys KDDa and written into 
the purses. Likewise, the purses are subdivided in a number of groups, each of 
which receives a different key derived from KMb • These ” group keys” are again 
derived by SAM ID and written into the SAMs. At the beginning of a purchase 
transaction a unique session key is calculated by purse and SAM partly using, 
partly deriving common key material. 

To allow the replacement of compromised keys, the keys derived from KMa 
are dynamically updated during the life of the Proton System. This is where 
the Reversed Dynamic Key Handling is applied. For simplicity, we will in our 
explanation of RDKH ignore the double key hierarchy. 

The keys KDa are dynamically updated during the life of the Proton system. 
The time interval between two key updates is called a period. The subsequent 
periods are identified by the period number PNpp, that is managed centrally 
by the Purse Provider. Obviously, an update of the keys KDa affects the keys 
KDDa. Hence this dynamic key mechanism implies both key updates for the 
SAMs as for the purses. Since a key update requires the SAM or purse to be 
on-line with the Purse Provider Host/HSM, a simultaneous update of all these 
keys is not realistic. It is therefore necessary to have a mechanism that allows 
transactions between purses and SAMs with debit keys corresponding to different 
periods. This is realised in the following way. 

A SAM must contact the Purse Provider Host/HSM at fixed intervals to 
collect its revenues. When the PNpp is incremented with respect to the previous 
collection, a new period has started and the key KDa is loaded. A merchant 
terminal is assumed to be on-line at least once a period, hence its SAM contains 
the debit keys corresponding to the current period PNpp or the previous period 
PNpp-1. 

A purse comes on-line with the Purse Provider for load transactions. When 
the PNpp is incremented with respect to the previous load transaction of the 
purse, the keys KDDa corresponding to the previous period (PNpp — 1) are 
loaded. Since it may take several periods between two subsequent load trans- 
actions of a purse, a purse may carry keys corresponding to old periods. 
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The keys KDa have been generated in such a way that given KDa of a certain 
period, the corresponding key of the preceding period can be calculated, and by 
induction the keys KDa of all previous periods. However, the one-way property 
of the function used to generate these keys makes it infeasible to calculate keys 
corresponding to future periods. 

It can be seen that for any SAM/purse pair, the PN of the SAM keys is 
larger than or equal to the PN of the purse keys. In a transaction between a 
SAM and a purse with PNpurse< PNsam, the SAM starts by calculating the 
key KDa corresponding to the PNpm-ge- This consists of applying the one-way 
function ( PNsam— PNpurse) times to its current key. 

The dependencies between the keys involved in RDKH is illustrated in Figure 

o 




Key ID = 1024 



Key ID = k 



Key ID = k 



Fig. 5. RDKH key derivation 



5 Conclusions 

We have presented two methods for the dynamic handling of diversified secret 
keys. 
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Abstract. The first part of this paper is devoted to explaining what 
key escrow is and why it exists, and attempts to put it into a historical 
context. The subsequent focus is primarily on key escrow schemes which 
will work in an international environment. The possibility of using con- 
ventional key distribution techniques to provide key escrow services in 
an international context is first considered, and the associated problems 
are explored. The ‘Royal Holloway’ (RH) key escrow scheme is then de- 
scribed in a way which is intended to clarify and motivate its design, and 
the properties of this scheme and some related schemes are considered. 



1 Introduction 

In the last two or three years there has been an explosion of interest in the ‘key 
escrow’ problem. Most recently this has given rise to an announcement from 
the US Government, and a simultaneous announcement from a group of major 
manufacturers, that export restrictions on encryption technology will be lifted 
for products incorporating key recovery facilities. 

The purpose of this paper is to explain what key escrow is and why providing 
it is non-trivial (at least in an international context), and to introduce a family 
of technical solutions. One motive for producing this paper is to give a sim- 
ple explanation of key escrow, and in so doing counter some of the widespread 
misconceptions about the nature of key escrow. To some extent these misconcep- 
tions arise from some of the wilder statements made by those parties opposing 
the principle of key escrow, often on extreme libertarian grounds. 

Of course, what kinds of key escrow solutions should be implemented, if any, 
is a practical and political question, and one which is beyond the scope of this 
paper. The purpose of this paper is certainly not to argue for or against the 
principle of key escrow, but to attempt to provide a simple explanation of some 
of the technical issues. Only against such a background can a measured debate 
about the rights and wrongs of the use of the technology be played out. 



* Work supported by EPSRC grant number 94007824. 

** Chris Mitchell is currently at: Europay International, Chaussee de Tervuren 198A, 
B-1410 Waterloo, Belgium, whilst on leave from the University of London. 



B. Preneel, V. Rijmen (Eds.): COSIC’97 Course, LNCS 1528, pp. 277-1203 1998. 
(c) Springer- Verlag Berlin Heidelberg 1998 



278 



Mark P. Hoyle and Chris J. Mitchell 



2 Key Escrow 

2.1 Background 

It is an undisputed fact that the rapidly growing use of public telecommunica- 
tions and computer networks for sensitive and commercial applications argues 
strongly in favour of the widespread public use of cryptographic techniques. Of 
course, serious arguments do exist about how far we need to go in securing these 
networks, but these arguments tend to be about the level of security required, 
rather than about the need for any security at all. 

The most fundamental services which can be provided by cryptographic 
methods are confidentiality and integrity protection for transferred and stored 
data. We apply the term integrity protection to mean not only protection against 
accidental or deliberate change, but also the provision of means to verify the 
claimed origin of data. Integrity and confidentiality can be provided indepen- 
dently of one another, and indeed are typically provided using different mecha- 
nisms. 

Typically, integrity services will be provided by the use of a digital signature 
or a Message Authentication Code (MAC), and confidentiality will be provided 
by the use of encryption. For many commercial organisations, the primary secu- 
rity requirement is integrity, and confidentiality for transmitted data is at most 
of secondary importance. However, in recent years there has been an enormous 
growth in the use of public networks, in particular the Internet, for all kinds 
of applications, including many for which confidentiality is important. For ex- 
ample, encryption is probably essential for the security of electronic commerce 
over public networks; without confidentiality protection for users’ bank details, 
a variety of frauds may become possible. 

However, widespread encryption of user communications on an end-to-end 
basis, i.e. encryption at source and decryption at destination with no decryption 
between, presents a problem to police forces and other law enforcement agencies 
throughout the world. Currently, in many (probably nearly all) countries, certain 
official agencies may intercept telecommunications traffic, if so authorised by 
an appropriate legal process. Typically a police force wishing to intercept the 
communications of a suspected criminal can do so if granted a warrant from a 
judicial authority. 

Note that, at least within the UK, such legal interception powers are non- 
trivial to obtain. Typically, interception warrants will only be granted in cases 
of serious crime, e.g. crimes for which the first offence penalty would be a prison 
sentence of a year or more. Once a warrant has been granted, the collection 
of the intercepted data would normally be performed by the network provider 
(e.g. a public network operator) acting on behalf of the agency wishing to read 
the traffic. The involvement of another third party also helps make abuse of 
interception powers more difficult. 

Obviously, the widespread use of encryption will nullify this interception ca- 
pability. Observe that integrity protection through MAGs and digital signatures 
is not a problem in this respect, since it does not threaten the interception ca- 
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pability valued by law enforcement agencies world- wide. We are thus presented 
with the problem of reconciling the legitimate requirement of users and business 
for confidentiality of communications, with the requirements for legal intercep- 
tion. 



2.2 Key Escrow — A Solution? 

One solution to this problem, which has recently received very wide attention, 
is to use a key escrow scheme. The idea of such a scheme is that copies of the 
keys used by parties to encrypt their messages are lodged with escrow agents, 
and that, when an agency is given authorisation to intercept a particular user’s 
communications, they can apply to the appropriate escrow agent for a copy of 
that user’s key. An escrow key mechanism can then simply be regarded as a 
method of key generation and distribution such that users are equipped with 
encryption and decryption keys when they need them, and where all relevant 
escrow agents also have access to a copy of decryption keys (in the event that 
they are required by legally authorised parties). 

We therefore arrive at the following ‘model’ of a key escrow system, with 
three types of entity involved: 

1. Users are entities who wish to exchange confidential messages, 

2. Trusted Third Parties (TTPs), which can be further split up into two, not 
necessarily disjoint, groups: 

(a) TTPs offering trusted services (e.g. time-stamping and certification of 
public keys), 

(b) and KEAs (generally known as Key Escrow Agencies or Key Recovery 
Agencies) that provide a key management service to users and also pro- 
vide a key escrow/recovery service on demand, 

3. and an Interception Agency which will make use of an escrow agency to 
obtain keys when authorised to do so. 

This is, of course, a simplified model. Corporate entities may also wish to have 
the means to intercept encrypted traffic going to or from their employees, at least 
while it involves use of their equipment or communications facilities. In such an 
event companies, or parts of companies, may fit any or all of the above three 
roles (since companies may provide the key management for their own private 
networks) . 

The notion of Trusted Third Parties acting on behalf of users, but within 
a regulatory regime which requires them to divulge user secrets when legally 
required to do so, is a familiar one. Most banks fill precisely this role; they look 
after money for users, and will provide information regarding financial transac- 
tions to tax authorities when legally required to do so. 

In recent months a number of governments have suggested that they will 
encourage the development of encryption products incorporating a key escrow 
facility; in particular, the US Government has stated that existing export con- 
trols for encryption products will be relaxed if escrow is included. The current 
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approach appears to be to encourage voluntary adoption of such schemes, with- 
out forcing all users of cryptography to adopt them. Thus the existing user of 
home-built encryption software can carry on using it, even though it may not 
incorporate an escrow facility. However, if international use is required, then 
the legal controls on the export of encryption products will make use of such 
products much more difficult. This primarily voluntary approach would appear 
to reduce the threat perceived in some quarters regarding the loss of existing 
freedoms to use cryptographic techniques. 

One question that immediately arises in the context of voluntary (rather 
than compulsory) use of escrow technology, is ‘Why bother if all the criminals 
will not use escrowed technology’? There are a number of possible answers to 
this question, including, possibly, to admit that there is no point in bothering! 
However, to see why this might not be the case we need to examine in a little 
more detail how escrowed encryption might be offered and used. 

The main likely area of application for key escrow services is in public data 
communications networks, such as the Internet and data transmission services 
using mobile telephony. We might expect to see end-to-end encryption, with 
built in key management (and key escrow) support, being offered by either the 
provider of the network, or by independent network service providers. Commer- 
cial organisations, who may already buy in certain network services, and who 
also wish to have a confidential communications facility, would then subscribe 
to one of these key management services for confidentiality support. These or- 
ganisations would then enjoy the benefit of secure encryption technology being 
available on an international basis, whilst governments would be happy to allow 
free export of the necessary hardware and software, safe in the knowledge that 
interception using a key escrow service will be possible for their law enforcement 
agencies. 

Indeed, if all public networks offered a practically unbreakable encryption 
service without any provision for key escrow, criminals would find such a service 
extremely useful, and it would remove a valuable weapon from the armoury of 
those agencies which we collectively appoint, authorise and pay to protect us 
against the actions of criminals. Faced with the possibility of freely available 
encryption to all, governments are much more likely to prohibit encryption al- 
together, and/or widen the use of other, possibly more intrusive, methods of 
monitoring traffic. Thus the real alternative is probably not whether we use 
some kind of key escrow or not, instead it is whether we have encryption with 
key escrow or no public encryption service at all! 

We can now attempt to answer the question as to why criminals would use 
an escrowed network for their confidential messages, since they would surely be 
aware that law enforcement agencies could apply for a warrant to decrypt their 
encrypted messages. There are a number of reasons why we might expect this 
to happen. 

— Firstly there is the issue of convenience. It is to be expected that, at some 
time in the not too distant future, all public communications networks will 
offer an encryption option with automatic key management support. Grim- 
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inals are likely to use such an option, even if they know they may be inter- 
cepted, since they ‘might as well’ (it will cost them relatively little and will 
certainly not make life any easier for the police!). 

— Secondly we have a point regarding history. Criminals have continued to use 
the public telephone and postal networks in full knowledge of the possibility 
of interception. It seems rather unlikely that they would avoid use of public 
networks with an escrowed encryption facility. Moreover, they may wish to 
communicate with non-criminals, and in such a case they would be obliged 
to use standard network facilities. Of course the sophisticated criminals will 
use their own ‘unescrowed’ encryption, but this should not, in itself, pre- 
vent society from limiting the public availability of completely untouchable 
encryption. Most criminals are not sophisticated! 

Having considered two reasons why key escrow might continue to be a valu- 
able resource to society, we should also consider why anyone would worry about 
the idea of key escrow, given that, in most countries, everyone is already sub- 
ject to telephonic and postal interception. The usual answer of opponents is to 
suggest that this is one more step to a ‘big brother’ society. Whilst the prospect 
of constant electronic monitoring of all aspects of our lives is certainly not a 
welcome one, the introduction of key escrow does not necessarily do anything 
to bring this closer. Indeed, its introduction will not enable the state to do any- 
thing it could not do before, since the automatic collection of intercepted data is 
already an established technology, and all escrow will do is enable the continued 
use of such data for law enforcement purposes; indeed, it is possible to argue 
that it is non-escrowed encryption which threatens the status quo. 

Traditionally most European societies have managed to cope with the nec- 
essary compromises between individual privacy and the need to give the state 
certain limited powers to protect its population against serious crime. Ultimately, 
the decision about where lines should be drawn is a political one, and outside 
the scope of this paper. 

It is interesting to note that arguments about the rights and wrongs of key 
escrow often seem to mirror arguments about gun control. That is the arguments 
revolve around the conflict between individual rights to use a technology, and the 
protection of society, particularly its weaker members, against misuse of tech- 
nology by criminal elements. One argument against gun control, which precisely 
mirrors one of the arguments against key escrow, is that criminals will bypass 
such legislation. Of course they will, but there are still benefits from preventing 
the open sale of weapons, particularly in reducing armed crime. Of course, limit- 
ing the availability of weapons is a major loss of rights for an individual, and each 
society makes its own decision about the weight of the conflicting arguments. 

Finally note that there are other uses for key escrow technology, e.g. for com- 
panies to recover their data which may have been encrypted by an ex-employee 
who took the keys with them, which even some of the most vocal opponents 
of key escrow recognise as being potentially valid. This application is often re- 
ferred to as key recovery, although the difference between key recovery and key 
escrow is not always clear; indeed it would appear that in some circles the term 
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key recovery is used instead of key escrow. Certainly the idea that work on this 
technology is inherently a bad idea, in the same way that one might argue that 
work on nuclear weapons is immoral, now seems to be rather out of fashion. 



2.3 The International Key Escrow Problem 

As we see below, while it would appear to be relatively straightforward to design 
escrow systems which operate in a single domain (e.g. a large country), with a 
single legal framework, international use presents a number of problems. Some 
of the most significant problems are as follows. 

— There will typically be more then one intercepting body, normally at least 
one per domain. 

— A legal warrant issued in one domain will typically have no validity in another 
domain. Hence at least one escrow agent will need to exist in every domain, 
so that every intercepting agency has an escrow agent to whom they can 
pass a warrant. 

— Different domains will typically have different legal rules about to whom and 
in what circumstances a warrant can be issued for legal access to encrypted 
communications . 

— There may be a lack of trust between domains, making arrangements apply- 
ing to cross-border encrypted communications difficult to define and operate. 

In Section 0 we consider how solutions to the international problem may be 
devised. 



2.4 Some Historical Background 

For many years most western governments have sought to control cryptographic 
technology. There are two major reasons for these controls, which have mainly 
applied to ciphers rather than other types of cryptographic technique. Note that 
this concentration on ciphers is both for historical reasons (cryptography was 
the same as the study of ciphers until relatively recently), and because of the 
fact that confidentiality is the most politically sensitive of the services which 
cryptographic techniques can provide. 

— The first reason relates to national security; in particular governments typ- 
ically wish to intercept other countries’ communications. By limiting the 
export of equipment incorporating cryptographic facilities to ‘friendly’ coun- 
tries, the objective is to ensure that unfriendly countries use inferior ciphers, 
or perhaps none at all. This can then lead to a decisive military advan- 
tage. The importance of cryptography and cryptanalysis in war is well doc- 
umented, particularly in the case of the second world war. Indeed, the needs 
of cryptanalysts during the second world war played a major role in the de- 
velopment of modern electronic computers, as testified by the development 
of the ground-breaking Colossus machine at Bletchley Park. There has also 
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been a general desire to discourage public research in cryptography; although 
much research in cryptography has been conducted by academics and others 
since the 1970s, previously very little appeared in the public domain. Most 
developed countries maintain significant government-controlled interception, 
cryptographic and cryptanalytic capabilities, e.g. at GCHQ in the UK and 
at NSA in the US, whose research is most certainly not in the public domain, 
although publication by members of these organisations is not unknown. 

In recent years there have been many efforts by those inside and outside the 
cryptographic community to attempt to discredit the export controls that 
exist. It is certainly true that these controls have been incapable of stem- 
ming the flow of encryption software across the Internet, although laws are 
probably being broken every time these pieces of software cross international 
boundaries. However, computer experts who use such software are typically 
not the target of these controls, and the export of encryption hardware, 
which is often of key importance for military and paramilitary use, remains 
strictly controlled. 

— The second reason for control stems from the need of government agencies 
to intercept internal communications to combat crime. For example, police 
routinely ‘tap’ the telephones of suspected serious criminals, when provided 
with appropriate warrants. Although it would seem unlikely that a criminal 
would use a public communications network to discuss criminal activity, par- 
ticularly when the ability of the police to tap telephone traffic is well known, 
apparently they do, and the ability to tap telephone traffic is seemingly 
highly valued by law enforcement agencies. 



In order to limit the flow of cryptographic technology around the world, 
all implementations of cryptographic algorithms (hardware and software) have 
been subject to COCOM-based export regulations (these regulations have re- 
cently been replaced by the Wassenaar arrangement, although the effect of these 
controls appears to remain much the same). Since World War II these regula- 
tions have been very effective in limiting access by certain states to sophisticated 
cryptographic equipment. Whilst documentary evidence is very difficult to ob- 
tain, for obvious reasons, there is strong anecdotal evidence that this policy has 
been enormously helpful to western countries in a variety of conflicts that have 
arisen since 1945. 

In parallel with this control of export of cryptographic technology, some coun- 
tries, e.g. France, have regulated the internal use of cryptography. The main 
objective of these controls has been to limit the use of ciphers, although the 
French law covers all cryptographic techniques. This has met the needs of law 
enforcement agencies who wish to retain the right to intercept traffic. Other 
countries, e.g. the UK and US, have not regulated the internal use of crypto- 
graphy, possibly because cryptographic technology has not been widely available 
for use, and hence controls have been unnecessary. However, with the growth in 
personal computers and other cheap consumer electronics capable of perform- 
ing sophisticated cryptographic calculations, one might anticipate pressure in 
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some countries for the introduction of new legislative controls over the use of 
cryptography, and in particular of ciphers. 

In opposition to this is the growing legitimate need for end-to-end privacy 
over public networks. If the Internet and other public networks, such as mobile 
telecommunications networks, are to be used for commerce, then in many cases 
privacy for confidential user information is required. This in turn creates a grow- 
ing requirement for public use of encipherment technology. This tension leads 
naturally to the topic of key escrow. 

2.5 The Development of Key Escrow 

As far as the public domain is concerned, the history of key escrow started as 
recently as 1993, with the proposal by the U.S. government of the Escrowed En- 
cryption Standard ca, EES, also known as the CLIPPER scheme. This scheme, 
which we now briefly outline, only attempted to solve the problem for the US, 
and did not address the needs of users wishing to have communications confi- 
dentiality for trafflc entering or leaving the US. 

At the heart of the CLIPPER scheme was an encryption algorithm (the 
SKIPJACK algorithm) devised by the NSA, and which was intended to remain 
secret, although certain interface details were made public. Details would obvi- 
ously need to be released to selected integrated circuit manufacturers, but these 
manufacturers would be required to commit themselves to maintaining the se- 
crecy of the algorithm. A range of products would then be developed incorporat- 
ing the CLIPPER algorithm, for use by anyone in the US needing confidentiality 
for communicated data. 

To enable key escrow, all implementations of the algorithm were to incor- 
porate ‘key checking’ for all entered keys, i.e. checking that the key contains 
redundancy according to a particular (secret) cryptographic formula. How this 
was implemented is not clear, but it could have been arranged by adding a 
cryptographic check value to each key, computed using a secret key known only 
to the devisers of the scheme. 

Whilst such a scheme is a reasonable candidate for use within a single domain 
or country, it is less suitable for international use since it depends completely 
on the secrecy of a single algorithm. Once the algorithm is known to more than 
one entity, control of keys is lost, and the scheme becomes unworkable. On the 
other hand, leaving the control of all keys within a single country could never 
be widely acceptable. 

In the remainder of this paper we therefore focus on other types of solution 
to the key escrow problem. 

2.6 Key Escrow and the Public Key Infrastructure 

Before proceeding it is worth spending a few moments distinguishing between 
the Public Key Infrastructure (PKI) and TTPs providing Key Escrow services. 
Since they are both TTP-based and provide security services, it is easy to confuse 
the two; however the goals are typically very different. 
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The purpose of the PKI is to provide a means of distributing public signature 
verification keys on a wide, possibly global, scale. It is based on the idea of a 
network of Certification Authorities (CAs), signing public key certificates for 
individual users. These certificates consist of a copy of the public verification key 
for that user, concatenated with the user’s name, an expiry date, and certain 
other information, all signed using the CA’s private signature key. 

Anyone wishing to obtain the public verification key for another user, first 
obtains the public key certificate for that user, and then verifies the certificate 
using the public key of the appropriate CA. This yields a verified copy of the 
user’s public verification key, which can be used to check digital signatures on 
messages originating from that user. The certificates are typically, although not 
necessarily, distributed by means of directories, which need not be trustworthy. 

Thus the Public Key Infrastructure’s primary role is to support the wide- 
spread use of digital signatures. As such, it has been supported by governments 
and business world-wide, since there is much to gain and very little to lose from 
implementing global, secure, digital signatures. It will make certain types of 
fraud much more difficult, yet it will do nothing to interfere with the ability of 
government agencies to intercept communications. In fact, this notion fits well 
with the US government backed signature algorithm DSA, which has the great 
advantage that, unlike RSA, it cannot be used for encryption. 

Of course, in principle there is nothing to stop CAs signing certificates con- 
taining public encryption keys instead of public verification keys, although this 
is not the typical case. Such an idea is also likely to meet with government 
resistance because typically it will not allow key escrow. 

Key escrow, unlike the PKI, supports the widespread use of encryption, and 
simultaneously allows warranted interception to take place. There are many ways 
of providing key escrow, as we describe in the remainder of this paper, but typ- 
ically it involves a TTP handing over a user’s encryption key to an interception 
agency when warranted to do so. 

It is important to stress that key escrow relates to encryption keys and not 
signature keys. Some opponents of key escrow have, accidentally or deliberately, 
muddied the waters somewhat by suggesting that governments wish to escrow 
signature keys. Not only is this not justified by the evidence, but the fact is that 
the US and other governments have actively promoted the development of the 
PKI, which is quite orthogonal to the notion of key escrow. The development of 
the DSA standard can be seen as a very deliberate effort by the US to promote a 
secure signature technique which avoids export restrictions by being a signature- 
only algorithm, and can therefore be used world-wide; this is hardly the act of 
a body wishing to restrict the use of signatures. 

In fact governments and their law enforcement agencies have every reason 
not to escrow signature keys. The worst possible scenario would be for criminals 
to repudiate signatures on the basis that the government has access to their 
private signature key, and therefore a government agency must have forged their 
signature! 
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3 What Do We Want from a Key Escrow System? 

There are two main objectives/requirements for a typical key escrow system. 

— Warranted interception, i.e. the ability of an interception authority (typ- 
ically a government agency) to obtain the means to decipher intercepted 
enciphered messages and/or stored enciphered data, typically for law en- 
forcement and/or protection of national security. This is the main objective 
behind the CLIPPER proposal. Escrow schemes can be used elsewhere by 
having other parties play the role of the ‘authority’, e.g. companies, organi- 
sations, private persons. 

— Data recovery, i.e. the ability to recover plaintexts from ciphertexts in case 
of lost, damaged, or sabotaged keys. 

3.1 Requirements for Key Escrow 

There have been many papers and groups suggesting various requirements and 
constraints for key escrow systems. It is impossible to formulate a single uni- 
versally acceptable list, because the exact practical requirements will always be 
dependent upon the application of the system. In this paper we will confine our- 
self to giving just one list. This is a draft list of requirements produced by the 
UK Department of Trade and Industry (DTI), which, although not official UK 
policy, indicates the direction of DTI thinking on the role of TTPs in supporting 
key escrow services. 

1 The framework should provide benefits to the legitimate user. 

2 It should provide for both national and international working. 

3 It should be public and unclassified. 

4 It should use well known techniques. 

5 It should support all forms of electronic communication. 

6 It should be compatible with the different laws and regulations of participating 

countries concerning interception, use, sale and export. 

7 It should not impede the due process of law and order. In particular, it should 

allow near-real-time access when a warrant is held. 

8 It should provide access under warrant (or other legally-constituted form of 

authority) to both incoming and outgoing communications. 

9 It should enable the sender to limit the length of time for which any key is 

used. 

10 It should provide for the use of a variety of cryptographic algorithms whether 
in hardware or in software. 

11 It should not enable those with a warrant to fabricate false evidence. 

12 It should ensure that attempted abuse by the sender can be noticed by the 
receiver. 

13 It should not require a user to deal with a Trusted Third Party in another 
country. 

14 It should not require either regular or on-line communication between Trusted 
Third Parties. 
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This list is clearly intended to apply to international solutions (see require- 
ments 2 and 13). The technical solutions we describe later in this paper are 
intended to fit, as much as possible, to this list, which we refer to as the ‘DTI 
requirements’ (although this is not meant to imply that they are official DTI 
policy). 

Before proceeding note that, since we are concerned only with escrowing 
encryption keys, requirement 11 is not an issue here. Indeed, it is further evidence 
to contradict any suggestion that there is a requirement to escrow signature keys. 



3.2 Types of Warrant 

In the rapidly growing literature relating to key escrow, there has been a consid- 
erable amount of discussion regarding what the reasonable scope of an intercep- 
tion warrant might be; note in particular ITtIT^ . Such an interception warrant 
would typically be issued by a judicial authority to an interception agency, and 
will describe what access to users’ communications should be provided to this 
Interception Agency by a Key Escrow Agency. Of course, the exact nature of 
the key escrow system will determine what types of access can be readily pro- 
vided, and hence understanding what types of warrant will be issued gives a very 
important measure of the usefulness of a key escrow scheme. 

The most typical warrant would appear to be one which relates to a single 
communicating entity. Some authors suggest that it may be useful to be able 
to support separate warrants for all outgoing communications from this entity, 
and for all incoming communications to the entity. Others suggest that ‘time- 
bounding’ warrants is a very important requirement, i.e. so that the interception 
agency is only given access to an entity’s communications for a specified period 
of time (e.g. if they are given a key to decrypt enciphered communications, then 
it should stop working when the warrant expires, and it should also not work 
with messages sent prior to the start date in the warrant). 

The DTI requirements list in Section It. II only explicitly specifies that war- 
ranted access to all incoming and outgoing communications should be possible 
(see requirement 8), without separating the two. It does also refer to the need 
for a sender to be able to limit the time period for which any particular key is 
used, which implies a type of time-bounding (see requirement 9). We therefore 
restrict our attention mainly to the case where warrants cover communications 
both incoming to and outgoing from an entity, and where time-bounding may 
be a requirement. The requirement for separate send and receive warrants seems 
unlikely to be of much practical significance. 

Note that it is an implicit assumption of most key escrow schemes that inter- 
ception warrants only normally apply to communications either originating or 
terminating in the country (or domain) where the warrant is issued. Although 
other possibilities have been considered in the literature, see, for example, pini, 
we restrict our attention to this case. Even in this case, there are two possibilities 
for the entity covered by a warrant: 
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— the entity concerned is sending or receiving communications from within the 
domain of the interception agency, in which case all that entity’s communi- 
cations are covered by the warrant, or 

— the entity concerned is sending or receiving communications from a different 
domain to that of the interception agency, in which case only those com- 
munications which originate or terminate within the interception agency’s 
domain are covered by the warrant. 

Of course, these two possibilities are not mutually exclusive, given that users may 
migrate from one domain to another during the lifetime of a warrant; however, 
to simplify the discussion, we treat the two cases separately here. Finally observe 
that the first case can be considered as the ‘most typical’. 



3.3 Types of Solution 

Almost all of the proposed solutions to the key escrow problem adhere to a 
model similar to that described in Section 12.21 i.e. where TTPs act on behalf of 
both users and interception agencies. Again it is generally the case that these 
TTPs provide key management and/or key generation services for users, whilst 
at the same time providing keys to interception agencies (to enable decryption 
of intercepted messages). There are then two main ways in which such a key 
management scheme can work: 

— the encryption algorithm is fixed and secret (typically implemented in some 
kind of secure hardware), and only works with keys of a certain secret form 
(e.g. the Clipper scheme), or 

— the encryption algorithm is not fixed, and the key management system sim- 
ply arranges for the distribution of keys which may be used in a variety of 
algorithms. 

The advantage of the first type of scheme is that it prevents abuse, in that 
users have no alternative but to use officially issued keys, i.e. keys which are 
known by the Escrow Agency. The main disadvantage is that it prevents use by 
a multiplicity of TTPs in different domains (since each TTP needs to know how 
to generate keys), and hence is not suitable for international use. 

The main problem with the second type of scheme is that it opens up the 
possibility of abuse, i.e. of users making use of part or all of the key management 
scheme in order to establish a shared secret key for encipherment, but to ‘distort’ 
the scheme in such a way that the escrow agent does not have the correct key to 
decipher the encrypted communications. This is a possible problem we discuss 
further in Section ^31 below. 

Given that we are interested in solutions which can work in an international 
environment, we do not consider further escrow schemes of the first type (i.e. 
which are based around a specific secret algorithm), and we restrict our attention 
to solutions of the second type from this point on. 
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4 Possible Solutions Using Existing Key Distribution 
Methods 

In this section we examine solutions to the key escrow/recovery problem based 
on existing techniques for key management. We look at solutions in the light 
of international use and identify some problems involved with the use of these 
methods. 

4.1 Symmetric Cryptography 

Probably the most common solution to the problem of key distribution using 
symmetric cryptography is for the network(s) to provide a special type of TTP 
known as a Key Distribution Centre (KDC), i.e. a trusted network resource 
that shares a key with each subscriber and uses these in a bootstrap process to 
provide additional keys to the subscribers as needed. When one subscriber wants 
to communicate securely with another, he/she first contacts the KDC to obtain 
a session-key for use in that particular conversation. The KDC then generates a 
session key and provides the means for both users to obtain a copy of this in a 
way which preserves its confidentiality. 

Key distribution protocols vary widely depending on the cost of messages, the 
availability of multiple simultaneous communications, whether the subscribers 
have synchronised clocks, and whether the KDC has authority not only to fa- 
cilitate, but also to allow or prohibit, communications. In the discussions below 
we sketch two key distribution protocols; these are not complete specifications 
in that we ignore the provision of entity authentication, an important aspect of 
key distribution. However, depending on what methods are used for timeliness, 
e.g. time-stamps or unpredictable nonces (i.e. ‘challenges’ used only once), data 
items can be added to the messages specified (and, if necessary, preliminary 
messages added), to make the protocol provide mutual entity authentication. 
For details of how this can be achieved see, for example, ISO/IEC 9798-2 and 
11770-2, [iai3|). 

The protocols described are intended to be ‘typical’ examples of key distri- 
bution protocols based on symmetric cryptographic techniques. However, as we 
explain in the accompanying discussions, minor adaptations have been made in 
order that they can also support key escrow. 

The idea of modifying conventional symmetric cryptography based key dis- 
tribution protocols to support key escrow services is certainly not a new one. 
In Denning’s on-line catalogue of key escrow systems, which is a companion 
document to Denning and Branstad’s taxonomy, jSj, a number of mechanisms of 
this type are listed, including ‘Difhe Time-Bounded Clipper’ (1994), ‘Leiberich 
Time-Bounded Clipper’ (1994), and ‘PC Security Stoplock’ (1995). 

Single Domain with Single TTP The following example applies to the case 
where a single domain with a single TTP is involved. We suppose A wishes to 
send B a confidential message, where both A and B share a secret key (denoted 
Ka and Kb respectively) with a KDC. 
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1. A calls the KDC and requests a key for communicating with B. 

A — >KDC: A,B 

2. The KDC responds by sending A a pair of tokens. Each token contains a 
copy of the required session key Ks, one encrypted so that only A can read 
it, and the other so that only B can read it. 

KDC^A-. {Ks,A,B}k^,{Ks.A,B)ks 

where {X}k denotes the symmetric encryption of data X using key K. A 
can immediately decrypt the first token and obtain the session key Ks-, to 
be used between A and B. 

3. When A wishes to send a secret message M to B, A encrypts it under the 
session key, and sends it with both tokens to B. 

A^B: {M}ks,{Ks,A,B}k^,{Ks,A,B}k,. 

B uses the second token to recover Ks, the session key needed to decrypt 
M. 

4. Both tokens should also be sent with all subsequent messages (from A to B) 
which are encrypted using the same session key Ks- 

First note that the above protocol differs from a ‘typical’ mechanism of this 
type (see, for example, ^2]) in two respects. First it would normally only be 
necessary to send the second of the two tokens with the encrypted message in 
step 3. Second, in subsequent uses of the same session key, it would normally 
not be necessary to send any tokens. These two (minor) differences are present 
to allow for key escrow. Of course, even without the transfer of both tokens 
the interception agency could decrypt the messages with the assistance of the 
appropriate KDC (as long as the KDC retains a copy of the session key), although 
we wish to consider schemes here that involve the minimum interaction between 
Interception Agencies and KEAs (as in DTI requirement 7). 

Now suppose that the KDC is also licensed to act as a Key Escrow Agency. 
To be able to decrypt the communications between A and B, the Interception 
Agency will first need to obtain a warrant giving it permission to read either all 
A’s communications or all B’s communications. Once the Interception Agency 
has obtained this warrant, it presents it to the KDC, who hands over either Ka 
or Kb, depending on who the warrant covers. Armed with this key, and given 
any intercepted message, the appropriate token accompanying the message can 
be used to obtain the session key and decrypt the message. 

The scheme, as described, does not permit time-bounding of warrants. How- 
ever, this is not difficult to add to the scheme. One way of achieving this is as 
follows. Instead of using Ka to encrypt the token for A, the KDC uses a ‘daily’ 
key Sa, which is computed as a (public function) of the date and the key Ka, 
e.g. using a one-way hash-function; session keys are also changed at least once 
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per day. Given a time-bounded warrant valid for a set period of days, the ap- 
propriate set of ‘daily’ keys could then be computed in advance and passed to 
an Interception Agency, but these keys would not be of any use in decrypting 
messages sent at other times. 

Multiple Domains The previous scheme is unsuitable for use in more than one 
domain, since it uses a single TTP, but can be extended for use with multiple 
TTPs in multiple domains, and might even be suitable for international use. It 
operates as follows, where we suppose that A and B have separate TTPs, Ta 
and Tb, with whom they share secret keys, Ka and Kb, respectively. We also 
suppose that the two TTPs share a secret key KtaTb- 

As previously, we suppose A wishes to send B a confidential message. 

1. A sends Ta a request for a key for communicating with B (and an indication 
of who B's TTP is): 

A — > Ta : A, B, Tb 

2. Ta responds by sending A a pair of tokens. Each contains a copy of the 
required session key, one encrypted so that only A can read it and the other 
so that only B can read it. The encryptions are performed using newly 
generated keys and ATJ. Ta also sends to A, encrypted under Ka- 

Ta^A-. {K*a}k ,, , {Ks, A, B}ki,{Ks, A, B}k^^ 

where K\ = /{Kt^Tb i IDa), = HKtaTb . IDs), IDa and IDs are values 
(identifiers) uniquely identifying A and B, and / is a one-way function agreed 
between Ta and Tb (/ could be public and globally used). A first obtains 
the key K’^, and then decrypts the first token to obtain the session key Ks- 
Note that, instead of encrypting the tokens with A"^ and Kg, a ‘typical’ 
protocol of this type would simply use Ka to encrypt the first token and 
KtaTb to encrypt the second token; we make these minor changes both to 
permit key escrow and to reduce the amount of communication between B 
and Tb- 

3. When A sends a secret message M to B, A encrypts it using the session key, 
and sends it with both tokens to B: 

A^B: {M}ks,{Ks,A,B}kx,{Ks,A,B}k^^- 

4. When B receives the encrypted message and tokens, there are two possible 
cases to consider (we assume that B knows which TTP A is using). If B 
already knows Kg (which is a function only of the identity of Ta), then the 
protocol is complete. If B does not know Kg, then B sends a message to Tb 
requesting a copy: 

B^Tb-- Ta- 
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5. Ta now computes Kg, using the function / and the shared secret key Kt^Tb > 
and sends it back to B: 

Tb^B-. {K*b}kb- 

B can now recover Ks and use it to decrypt the message from A. 

6. Both tokens should also be sent with all subsequent messages (from A to B) 
which are encrypted using the same session key K$. 

First note that the above protocol differs from the ‘typical’ mechanism of this 
type in several minor respects. First, as we have already observed, the keys that 
would normally be used to encrypt the first and second tokens are Ka and Kt^Tb 
respectively. Second, as for the previous mechanism, it would normally only be 
necessary to send the second of the two tokens with the encrypted message in 
step 3, and, in subsequent uses of the same session key, it would normally not be 
necessary to send any tokens. These differences are present to allow for efficient 
key escrow, i.e., as previously, we wish to avoid the Interception Agency having 
to enlist the assistance of the KEA to decrypt every intercepted message. In fact 
these changes seem to improve the efficiency of the protocol at minimal cost even 
if key escrow is not required, and might usefully be considered for more general 
adoption. 

Now suppose that the KDCs are licensed to act as Key Escrow Agencies in 
their respective domains. To be able to decrypt the communications between 
A and B, the Interception Agency will first need to obtain a warrant giving 
it permission to read either all A’s communications or all i?’s communications. 
Once the Interception Agency has obtained this warrant, there are four cases to 
consider. 

— If the Interception Agency is in A’s domain and has a warrant to intercept 
all A’s messages, then the warrant is presented to Ta, who hands over K\ 
(this enables reading of all traffic from A to any user making use of the KDC 

— If the Interception Agency is in A’s domain and has a warrant to intercept 
all B's messages, then the warrant is presented to Ta, who hands over Kg 
(this enables reading of all traffic from any client of Ta to user B). 

— If the Interception Agency is in B's domain and has a warrant to intercept 
all A’s messages, then the warrant is presented to Tb, who hands over K^ 
(this enables reading of all traffic from A to any client of Tb). 

— If the Interception Agency is in B’s domain and has a warrant to intercept 
all B’s messages, then the warrant is presented to Tb, who hands over Kg 
(this enables reading of all traffic to B from any user making use of the KDC 

Ta). 

Armed with the appropriate key, and given any intercepted message, the appro- 
priate token accompanying the message can be used to obtain the session key 
and decrypt the message. 

The scheme, as described, does not permit time-bounding of warrants. How- 
ever, as with the previous scheme, it is not difficult to add time-bounding to the 
scheme, e.g. by including a date stamp in the calculation of K^ and Kg. 
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Evaluating the Mechanisms We now briefly consider how well these two 
schemes meet the DTI criteria, and how efficient they are. If we note that A 
can ask for a new session key whenever he/she wants (see DTI requirement 9), 
the protocol deals purely with encryption (see requirement 11), and that no real- 
time inter-TTP communications are required in either case (see requirement 14), 
the second protocol appears to have the potential to meet all the DTI criteria, 
with the possible exception of requirement 12, since the recipient has no means 
to check that the first of the tokens is sent correctly. The first protocol meets 
all the criteria except numbers 12 and 13 (this latter requirement fails since the 
protocol only makes use of a single TTP). 

As far as we are concerned here, the issue of ‘efficiency’ relates to the number 
of messages that need to be exchanged to support use of the protocol, particularly 
messages between a user and his/her TTP. In both mechanisms, A needs to 
exchange messages with his/her TTP to set up communications with B. In the 
first mechanism B has all that he/she needs to read the message without further 
exchanges with the KDC; however, in the second protocol an extra exchange 
between B and B’s TTP may be required to read the message. 

The system could become rather unmanageable for very large global net- 
works, because the TTPs are directly involved in setting up all communications, 
and hence are likely to become a significant bottle-neck. Of course these prob- 
lems apply just as much to unescrowed secure networks where key management 
is based on the use of symmetric cryptography. 

Also note that every pair of TTPs will need to have access to a shared 
encryption algorithm. If the scheme were to be used on a global scale, this in 
itself could present significant implementation difficulties. 

Despite these reservations, it should be clear that symmetric cryptography 
based mechanisms have the potential to meet all but one of the main require- 
ments for an escrow scheme. The main limitations are the usual limitations of 
symmetric cryptography based key management schemes, i.e. the need for on- 
line access to TTPs by both sender and recipient. 

In the remainder of this paper we consider ways in which the use of asymmet- 
ric cryptographic techniques can be used both to reduce the number of message 
exchanges, and, perhaps most importantly, to reduce the need for on-line com- 
munications between a user and a trusted third party (and hence reduce the 
‘bottle-neck’ problem). Typically, the use of asymmetric cryptography allows 
the substitution of an untrusted distributor of certificates for the on-line TTP 
required when symmetric cryptography is used for key distribution. As we shall 
see, this result extends, at least partially, to the case where the key distribution 
mechanism also needs to support key escrow. 



4.2 Asymmetric Cryptography 

We start our discussion of public key based schemes by considering the usefulness 
of conventional asymmetric cryptography based key distribution techniques for 
supporting key escrow. 
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We assume the reader is familiar with the notion of asymmetric or public 
key cryptography, as introduced in 1976 by Difhe and Heilman Public-key 
encryption is usually based on difficult number theoretic problems (e.g. factor- 
ing, discrete logarithms), which involve computationally complex calculations 
with large numbers. Thus public key encryption of entire messages is typically 
too time-consuming, and so it is common to employ a combination of symmetric 
and asymmetric cryptography. For confidentiality purposes, the message is (sym- 
metrically) enciphered with a randomly generated session key, and this ‘short’ 
session key is (asymmetrically) enciphered with the public encryption key of the 
receiver. The asymmetrically enciphered session- key is sent along with the enci- 
phered message. On delivery, the receiver can use his private decryption key to 
find the session key, and hence decrypt the message. 

By setting up a directory of certificates of users’ public encryption keys it 
is possible to set up a communication infrastructure allowing any two users to 
communicate securely. This would be precisely analogous to the Public Key 
Infrastructure referred to in Section E21 with certificates containing public en- 
cryption keys instead of public verification keys. 

In order to allow warranted interception we could require all Certification 
Authorities to obtain and store a copy of every user’s private decryption key 
before they sign the user’s public encryption key. This private key could then be 
handed over to an interception agency in possession of an appropriate warrant. 
The agency could then use it to obtain all the session keys used to encrypt 
messages sent to a specified entity. 

There are two problems with such an approach. The first is that obtaining 
a specific private key will involve approaching the appropriate CA, which might 
reside in a different domain from that where the interception warrant is issued. 
This breaches DTI requirement 13, i.e. the use of this type of scheme does not 
permit international operation. 

The second, even more fundamental, problem with this approach is that, 
while it is fine for providing warranted access to all the confidential messages 
received by a specified entity, providing warranted access to all messages sent 
by a specified entity is much more difficult. This is because each message to a 
different recipient will be protected using a different public key (i.e. the public 
key of the recipient). This leaves the interception agency with no choice but to 
approach the escrow agent with a request for the session key for each intercepted 
message, an approach which will become hopelessly inefficient and will, in most 
cases, breach DTI requirement 7. 



US Public Key Infrastructure (Clipper III) A recent, unofficial draft of the 
US Interagency Working Group on Cryptographic Policy I2D1 envisions a form of 
key escrow incorporated in a government-sponsored, voluntary PKI, usable for 
both confidentiality and integrity. The PKI itself would be supported by private- 
sector key-management organisations (certifying authorities). These would also 
hold in deposit private encryption keys, and will operate within performance 
standards set by law. Thus, they serve as a Key Escrow Agency (KEA). 
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This type of scheme is very much of the category we have just discussed, and 
hence one problem with this scheme, which will affect its usage on an interna- 
tional basis, is that the receiver’s private key is needed for the decryption, not 
the sender’s. Thus, if someone suspected of criminal activities sends a message 
to a ‘good user’, law enforcement require cooperation of the receiver’s KEA to 
decrypt the message with the good user’s private key. This is exactly the type 
of problem we have just considered. Indeed, this type of solution would appear 
to fail to meet DTI requirement 7. 

To use this scheme internationally would require co-operation between the 
receiver’s KEA and the law-enforcement agency in the sender’s country, which, 
in general, would be impractical. As we have already seen, this would appear to 
rule out this type of solution in an international context. 

Thus what we require are new types of public key solution allowing key escrow 
in an international context, as well as permitting simple warranted access to both 
sent and received messages. We can achieve this through the notion of separate 
‘send’ and ‘receive’ key pairs, as we describe in the next section. 

5 New Types of Solution 

We now describe a series of key distribution mechanisms allowing key escrow, all 
based on the use of public key cryptography. The schemes have been designed to 
work in different operational environments. We start with the simplest scheme, 
which applies to a single domain environment. 

Before proceeding observe that all the mechanisms we describe here are vari- 
ants of the Difhe-Hellman key agreement mechanism, We therefore assume 
that there is a globally agreed (large) prime p, and also a globally agreed primi- 
tive root g in the multiplicative group of non-zero elements in hp. All calculations 
are performed modulo p. 

We assume that the parameters are chosen so that the discrete logarithm 
problem is intractable, i.e. so that given an arbitrary h in h*, it is computation- 
ally infeasible to find an s such that = h mod p. 



5.1 Single Domain Solutions 

The concept of a domain can be likened to (and generally is considered the same 
as) a country. This domain can contain just one or multiple TTPs. We assume 
that there exists some level of trust between all TTPs, and that a single legal 
framework covers the whole of the domain. 

Our model for single domain solutions is a simple one. We assume that there 
are a number of TTPs. Each interception agency is able to communicate directly 
with every TTP, and there exists an agreement between each interception agency 
and each TTP that the TTP will give up the appropriate data when presented 
with a warrant by the interception agency. This could, for example, be achieved 
by requiring TTPs to operate within a legally backed regulatory framework. 
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We suppose that each user X has two private/public key pairs: a send key 
pair (S's(X), Ps(X) = modp) and a receive key pair (Sr{X), Pr{X) = 

gSr(X) pj^ 

All the private keys are registered with the user’s TTP (Ty) prior to cer- 
tification, and hence prior to use of the scheme. Certificates of the send and 
receive public keys are generated and marked as valid for encryption (certifi- 
cates marked as valid for signature will be treated separately, and the private 
keys should definitely not be lodged with any TTP). We suppose that the cer- 
tificates for all receive public keys are put into a universally available directory, 
and that all TTPs cross-certify each other and put all their cross-certificates 
in this directory; by this means any user can obtain the public receive key for 
every other user. In addition we suppose that every user is given a copy of the 
certificate for their own public send key; label the certificate for A’s public send 
key Ps{X) (which is signed by Tx)- CeitTx{Ps{X)). Note that this notation is 
not meant to imply that certificates only contain a copy of a user’s public key; at 
minimum they must also contain an identifier for the key’s owner, and typically 
they will also contain an expiry date, an algorithm identifier, and other relevant 
information. 

We now consider how the scheme will be used to provide key management for 
message encryption. We subsequently describe how warranted interception will 
operate. We suppose that user A (with TTP Ta) wishes to send a confidential 
message M to user B (with TTP Tg). 

The sender A needs the public receive key mod p) of the recipient B, 

and can get it either from a directory, or directly from B’s TTP (Tb). A then 
uses its own private send key (S's(A)) to compute the value 

(gSAB)fAA) niodp = gSAB)S,(A) ^^d p. 

A then selects a session key Ks, encrypts Ks using g^’-(^')^AA) encrypts 

the message using Ks, and sends the following message to B: 

A > B : {M}ks, {Ks}gSr(B)SXA) mod p 1 Pr{B),CeTtTAPs{A)). 

When B receives this message, B first verifies the certificate to obtain a copy 
of A’s public send key: Pb{A) = g^AA) modp. B then combines this with B's 
private receive key Sr{B) to obtain the value g^r(^')^AA) j^odp. B can then use 
this to decrypt the session key it's, and thence decrypt the message M. 

B uses the supplied value Pr{B) to determine which of its private receive keys 
should be used to compute the shared secret key with A. Note that, unlike the 
symmetric mechanisms described in Section H. II this mechanism does provide 
DTI requirement 12, because (implicitly or explicitly) B checks all the key data 
sent with the encrypted message. 

To see how warranted interception operates we simply observe that knowledge 
of any user’s private send and receive keys will immediately enable all messages 
sent or received by that user to be decrypted (since all the necessary public keys 
are always sent with a message) . This is the reason for introducing separate send 
and receive keys. Thus, if an Interception Agency has a warrant to intercept A’s 
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communications, then this warrant is passed to ^’s TTP Ta- The TTP then 
hands over A’s private send and receive keys, which can then be used to provide 
access to all tPs in- and out-going messages. 

As described, the mechanism does not provide time-bounding of warrants. 
Of course A and B can request new send or receive key pairs whenever they 
wish, giving a certain measure of time-bounding. However, to introduce a more 
sophisticated method of time-limiting warrants, we need to first describe the 
multi-domain version of the mechanism (see below) . 

In general, the mechanism offers a significant advantage over the correspond- 
ing symmetric cryptography based mechanism in reducing the possibility of TTP 
bottle-necks, since none of the TTPs need to be on-line and all public keys are 
distributed by means of certificates. 

Finally we observe that this mechanism is not appropriate for a multi-domain 
environment. This is because we assumed that the interception agency had access 
to all the TTPs, which will not be the case in an international environment 
(see DTI requirement 13). As we see below, to solve this we introduce a key- 
derivation technique similar to that used in the symmetric crypto based multi- 
domain mechanism introduced in Section PTfl 

Note that the single domain case is where most of the work in the public 
domain lies, but unfortunately much of these results are not very useful in the 
international case. The harder problems would appear to lie in devising multiple 
domain solutions that are both efficient and secure, and this problem is what we 
next consider. 

5.2 Multiple Domain Solutions 

The boundary line between solutions designed to operate in multiple domains 
within a single country, and international solutions is very fine. It can be argued 
that multiple domain and international key escrow schemes both have the same 
requirements. Fundamentally, international solutions do not rely on there being 
trust between domains, and need to be flexible enough to allow cooperating 
domains (countries) to implement different cryptography polices on the domestic 
and international use of encryption in a coherent way. 

The need for key escrow systems which support international use is by now 
well documented. In addition to the original papers describing the RH scheme, 
C3ISI. the 1995 paper of Frankel and Yung, m, discusses such a need. We now 
describe the RH scheme in the context of our previous discussions. 

The Royal Holloway Scheme The scheme which has become known as the 
Royal Holloway (RH) Scheme was first described in a pair of papers presented 
at conferences in 1995, mm-, an elaborated description of the scheme was 
presented in HS|. We specify the scheme here as a natural evolution of the 
schemes we have already described, in an attempt to clarify the motivation 
behind its design. 

If we consider the Diffie-Hellman based scheme described in Section Em it is 
straightforward to see that one obstacle to its use in an international context is 
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that the sender does not have an obvious means to obtain the recipient’s receive 
public key. However, if the receive public key is a function of a key shared between 
TTPs (as in the second mechanism described in Section lOl . then the sender’s 
own TTP can provide the necessary information. This is the basis of the RH 
scheme, which we now describe. 

We suppose that the TTPs acting as KEAs are trusted by their users and 
by the interception authority in their domain. We let Tx denote the trusted 
third party of user X. Just as in Section O we suppose that each user has 
two public/private key pairs, a send key pair and a receive key pair. Again, just 
as before, every user’s send key pair is registered with their own TTP, and the 
TTP retains a copy of the private send key and generates a certificate for the 
public send key. The only difference is that the receive key pair for any user is 
a deterministic function of a secret key shared by a pair of TTPs, as we now 
describe. 

Suppose A (with TTP Ta) wishes to send a secret message M to B (with 
TTP Tb). Analogously to the second mechanism in Section l4.1| we suppose 
that Ta and Tb share a secret key Kt^Tb! ^md have also agreed on a Difhe- 
Hellman key generation function /, which on input of a key K and an identity 
value IDjsf returns a secret receive key for user X. Then, the secret receive key 
for user B (for use when receiving messages from clients of TTP Ta) will be 
Sr{B) = f{KTATs , IDs), where IDs is a value uniquely identifying user B. 

Observe that this means that a different receive key pair will be needed for 
each TTP from whose clients a user wishes to receive mail. 

We can now describe the protocol. We use identical notation to that estab- 
lished above. We suppose that, when A chooses his/her TTP, a send key pair 
for A is chosen (Ss(A), Ps(A) = modp), and that Ta generates a certifi- 

cate for Ps{A) and passes it to A {Ta also retains a copy of Ss{A). Label this 
certificate Certr^ {Pg (A)) . 



1. A sends a message to Ta that he wants to communicate with B (who has 
TTP Tb). 

2. Ta generates the private receive key for B (for receiving messages from 

clients of Ta) as Sr{B) = /(ATtaTsADb) and computes the corresponding 
public receive key for B, i.e. Pr{B) = modp. Ta now sends Pr{B) to 

A via an authenticated channel. Note that this channel does not need to be 
confidentiality preserving, and hence the key could be sent in a certificate via 
a ‘regular’ communications channel. In fact the key could even be generated 
in advance and lodged in a public (not necessarily trustworthy) directory. 
Of course, there does need to exist a secrecy-preserving channel between A 
and Ta for the transfer of A’s private key whenever it is changed, but this 
will typically occur relatively infrequently (e.g. once a week). 

3. A computes a shared secret key as 



K{A,B) = P^(R)^A^) modp, 
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generates a random session key Ks (for encrypting M), and sends the fol- 
lowing to B: 



{M}KsAKs}KiA,B),CeTtTAPs{A)),Pr{B). 

Note that Pr{B) is present both to enable key escrow and to enable B to 
determine which of its private receive keys should be used to construct the 
shared secret with A. 

4. B verifies the certificate containing ^’s public send key and computes 

K{A, B) = Ps{Af'-^^'> mod p. 

This provides the means to decrypt K$ and thereby recover M . 

First note that B only really needs to verify the Certificate for A’s public key 
if the ‘shared secret key’ K{A,B) is to be used to support integrity protection 
as well as confidentiality protection. Note also that if B is going to verify the 
certificate for yl’s public key, then B needs Ta’s public verification key. Thus, 
should certificate verification be needed, on the first occasion that B receives a 
message from a client of Ta, B will need to ask his TTP to provide an integrity 
protected copy of Ta’s public verification key. This could be achieved by sending 
a certificate via a ‘regular’ communications channel, or via a public directory. 

It is worth remarking at this point that the scheme is very similar to the single 
domain public key solution. As we have already mentioned, the only significant 
difference is that every entity’s receive key pair is a deterministic function of a 
key shared by two TTPs. 

To see how escrow works we need to consider four cases. 

— If the Interception Agency is in A’s domain and has a warrant to intercept 
all A’s messages (or at least all messages sent by A), then the warrant is 
passed to Ta, who hands over S's(A). This enables all messages sent by A 
(to any domain) to be read, by combining the secret key with the public 
key sent with the encrypted message. This explains why the TTP Ta needs 
to be equipped with A’s private send key Ss{A); if this key was not in the 
possession of Ta then escrow would be much more difficult to achieve (and 
would have to be handled on a recipient by recipient basis). 

— If the Interception Agency is in B’s domain and has a warrant to intercept 
all B’s messages (or at least all messages received by B), then the warrant 
is passed to Tb, who hands over Sr{B). This enables all messages received 
by B (from clients of Ta) to be read, and thus Tb may need to hand over a 
selection of such keys, one for each TTP from whose clients B may receive 
messages. 

— If the Interception Agency is in A’s domain and has a warrant to intercept 
all B’s messages (or at least all messages received by B), then the warrant 
is passed to Ta, who hands over Sr{B). This enables all messages received 
by B from clients of Ta to be read. 
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— If the Interception Agency is in B’s domain and has a warrant to intercept 
all A’s messages (or at least all messages sent by A), then the warrant is 
passed to Tb, who can only help by providing individual shared secret keys. 

Thus escrow is relatively simple in all but the last case. Given that the first two 
cases are much more likely to occur than the last case, we can say that DTI 
requirement 7 is ‘mostly’ met. 

The scheme, as described, does not permit time-bounding of warrants, ex- 
cept that all entities can change their send key pairs as often as they wish. To 
enable receive key pairs to be changed regularly, which will provide the desired 
time-bounding, is simple to arrange. When computing receive private keys as a 
function of a TTP shared secret and an identity, a date stamp can also be added 
into the scope of the function, which means that every day a different receive 
key will be generated automatically. This idea is already described in tnmi . 
Note that there is a performance penalty associated with time-bounding, which 
increases as the time-bounding granularity becomes finer, since every new secret 
receive key needs to be transferred to its owner. 

The above scheme also appears to meet all the DTI requirements. Require- 
ment 9 is met by allowing the sender to change their key whenever they wish. 
Requirement 12 is met because, as in the previous mechanism, B checks all the 
fields in the received message (either implicitly or explicitly) . 

We conclude by comparing the mechanism with the symmetric mechanisms of 
Section 14.11 Although the general communications structure is closely analogous 
to the second mechanism in Section o there are the expected efficiency gains 
we would expect from using a public key solution. Notably, the communications 
between the sender and his/her TTP could be ‘off-line’, i.e. the required public 
key could be obtained via a directory, and also the message recipient has a 
minimal need for communication with his/her TTP (the recipient needs only 
contact his/her TTP for new receive key pairs, which could be done on a daily 
or weekly basis) . There is also only a need for a shared key between TTPs, and 
not a shared encryption algorithm. Finally, the RH mechanism meets all the 
DTI requirements, which is not quite the case for the symmetric mechanisms. 



A Variation on the RH Scheme We now consider a variation on the RH 
scheme; note that other variations, including support for ‘split escrow’, have been 
described in [E|. We suppose now that both the send and receive key pairs for 
every entity are deterministically generated as a function of keys shared between 
pairs of TTPs. In fact this means that the send and receive key pairs can actually 
be the same, and so from now on we just refer to the key pair for user X, written 
(S{X), P{X) = modp). This also means that all key pairs are specific to 
the TTP of the user who is to be communicated with, i.e. every user will have a 
set of key pairs, one for each TTP with whose clients the user wishes to exchange 
secret messages. 

This variation of the RH scheme thus has the advantage that the keys pro- 
duced can be used for two-directional communications (this would not be so 
simple for the ‘standard’ RH scheme because a receiver’s TTP has no direct 
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way of finding the sender’s public send key) . Moreover the TTPs do not have to 
archive the secret keys of their users. It does have the disadvantage (by compar- 
ison with the RH scheme) that the users initially have no method of controlling 
exactly when the values of their secret send keys are changed. However, this 
is not an abnormal situation: mobile phone users and users of many current 
encryption/security products, do not have any control over the values of their 
keys. 

The definitions used in the revised scheme are almost the same as before. 
We suppose that A (having TTP Ta) wishes to send a secret message M to B 
(with TTP Tb). We also suppose that, in advance of the use of the protocol, 
A is equipped by Ta with key pairs (and public key certificates) for use with 
clients of a variety of TTPs (including Tb). To simplify the description below we 
suppose that (S'(H), P(H)) is H’s Private/Public Key pair for use in exchanging 
messages with clients of Tb, and (S{B), P{B)) is B’s Private/Public Key pair 
for use in exchanging messages with clients of Ta- 
The protocol operates as follows. 

1. A sends a message to Ta that he wants to communicate with B (who has 
associated TTP Tb). 

2. Ta computes the private key for B as S{B) = /(Kt^TbjIDb) and computes 

the corresponding public key for B as P{B) = mod p. Ta now sends 

P{B) to A via an authenticated channel (as previously this would typically 
be by means of a certificate, or even conceivably via an untrusted third 
party). 

3. A computes a shared secret key as 

K{A,B) = P{B)^^'^'> modp, 

generates a random session key Ks, and sends the following to B: 
{M}Ks,{Ks}K(A,B),CevtTAPiA)),P{B) 



4. B verifies the certificate containing H’s public key and computes K{A, B) = 
p(yl)S'(B) jnod p. This provides the means to decrypt Ks and thereby recover 
M. 

As with the ‘standard’ RH scheme, B only needs to verify the certificate 
for A’s public key if K{A,B) is to be used to support authentication as well 
as encryption, and, in this case, B will need to be provided with Tas public 
verification key. 

Escrow works even more simply than for the ‘standard’ scheme. In each of the 
four cases described above, the TTP concerned can hand over the appropriate 
private key for the entity named in the warrant. 

One possible shortcoming in the scheme is that a sender now has no control 
over their key pair, and cannot change it ‘at will’ (see DTI requirement 9). 
However, by including a date stamp within the scope of the function used to 
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compute private keys, all key pairs are automatically of time-limited validity, 
and hence the scheme can be made to support full time-bounding (and, to all 
intents and purposes, DTI requirement 9). 

Another possible shortcoming is that every user must store a number of 
key pairs, one for each TTP with whose clients they wish to exchange secret 
messages. Whilst this is not ideal, this is already largely true for the ‘standard’ 
RH mechanism, since every user of that scheme must store a receive key pair for 
each TTP from whose clients they wish to receive secret messages. 

In terms of efficiency, the protocol is very similar to the previous scheme. Like 
the previous scheme, the sender of a message will need to obtain the recipient’s 
public key from an on-line entity (at least the first time a message is sent), 
although the recipient will normally have all that he/she needs to process a 
received message. 

5.3 Cheating 

One method of modelling a general class of key escrow schemes based on a public 
key infrastructure, derived from P], is to divide an encrypted communication into 
four components. 

Cl The actual message encrypted with a symmetric encryption algorithm, using 

a random session key Ks- 

C2 The session key Ks encrypted using the public key of the receiver. 

C3 The session key Ks encrypted using the public keys of one or more TTPs. 
C4 Other data. 

Generally a user will encrypt the session-key under the public keys of the 
receiver, the sender’s TTPs and the receiver’s TTPs. These TTPs, who are 
able to decrypt the message but are not actually sent the message, are known 
as virtual addressees. It is also possible to add more virtual addressees to the 
message, for instance TTPs in any domain through which the encrypted message 
travels (although in this case the sender must know the route that messages 
take), making this a fairly flexible concept. 

Not all these components may be present in each of the current key escrow 
schemes. For instance those schemes that escrow the user’s secret keys, e.g. the 
RH scheme (and its variations), tend to have no C3 component since the TTPs 
already have access to the appropriate secret key(s). In fact the RH scheme does 
not fit this model very well, since the RH scheme is a combined key escrow 
and key distribution scheme, and has meeting DTI requirement I as one of its 
objectives. 

This model is the basis of several key escrow systems: TIS-CKE 1 1 124] . IBM 
SecureWay HH, AT&T CryptoBackup and many others, and has the advantage 
that the users do not have to deposit secret key information with KEAs be- 
forehand. The flexibility of choice of TTPs also makes it suitable for use in the 
international environment. 

Although this approach is very flexible, unfortunately it is not fraud-resistant. 
Its main drawback is that only the TTP and receiver can check whether the 
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third component actually contains the correct session key; and the TTP can 
only detect this fraud after a lawful wiretap. Hence, by sending random data in 
place of C3, unilateral abuse is possible. This can be prevented by the addressee’s 
client software recalculating and validating C3 before decryption. However abuse 
by colluding of sender and receiver, through a one-time manipulation of the 
software, is still possible. 

In 1^ and |^, the authors address this problem using a novel concept called 
Binding cryptography. They add a fifth component (C5), to the communication, 
which contains ‘binding data’, with the idea that any (third party) monitor 
who has access to components C2, C3 and C5 (but not any additional secret 
information) can determine whether the session keys encrypted in C2 and C3 
are the same, but not actually obtain any information on the actual session key. 
How effective this scheme will be in preventing cheating remains to be seen. 

Finally we note that attempting to prevent ‘cheating’, while useful, is always 
likely to be of limited value, since once there is an infrastructure supporting 
the provision of authenticated channels between users, any pair of users can 
establish a shared secret key without any support from TTPs simply by using 
Difhe-Hellman key agreement. 

5.4 Variations to Fit Different Environments 

We now briefly consider two other possible requirements on key escrow schemes. 
Firstly note that, within the context of international communications, it is pos- 
sible that some countries may not want encrypted information crossing their 
jurisdiction without them having access to decrypt it. Obviously, this is a mat- 
ter of policy agreement between the domains concerned, although we note that 
it is unlikely to be a very common requirement. 

Indeed, such a requirement is specifically ruled out by the ITU rules. To 
quote from ITU (1992) CV/ Article 40 on Secret Language (para. 506): 

Members which do not admit private telegrams in secret language origi- 
nating in or destined for their own territory must let them pass in transit, 
except in the case of suspension of service provided for in Article 35 of 
the constitution. 

Nevertheless there may in certain special circumstances be a need for key escrow 
schemes which support it. 

Very few of the schemes which have so far been published address this prob- 
lem, with the exception of TIS-CKE [ I I24j , and the scheme in |Sj . The TIS-CKE 
scheme operates using the notion of virtual addressees. 

More generally, if we consider the components C1-C4 of encrypted messages, 
as introduced in the previous section, it is fairly easy to add extra encryptions 
within component C3 to enable Law Enforcement authorities in any domain 
that the encryption may pass through to decrypt it. Obviously the sender is 
going to have to know the route that the message takes beforehand. 

Secondly observe that it has been suggested that, to make key escrow more 
costly and hence restrict its use, the communicating parties should retain (and 
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not escrow) a variable amount of the key material needed for message recovery. 
This retained key material must then be recovered by the Interception Agency 
by exhaustive search techniques. Ideas of this type have been explored in EMU, 
and in HD this is called the residual work factor. This option could be used to 
increase the overall workload involved in key recovery so as to discourage ‘casual’ 
recovery requests and/or to inhibit ‘mass decryption’ of communications. This 
would typically be implemented by giving the KEAs all but, say, 40 bits of the 
session-key, thus requiring the interception authority to do an exhaustive search 
over the remaining bits. 

One major problem with such an idea is how to decide the amount of key 
material retained. If it is too small then there is little point. If it is large enough 
to make a difference, then it will impede the legal process. It would seem that this 
requirement is also unlikely to become a common one, since the only parties to 
gain would be the manufacturers of the computing equipment necessary to search 
through the large numbers of keys involved. Instead of putting artificial hurdles 
in the way of the legal interceptor, a better solution might be to ensure that 
the legal and auditing processes involved in providing access to both intercepted 
messages (typically involving a network provider) and escrowed keys (via the 
KEA) prevent simple abuse. In fact, whilst the bulk of network traffic and stored 
data remains unencrypted, as will probably be the case for some years to come, 
the main threat is not large scale key escrow but large scale interception of 
unencrypted traffic! 



6 Conclusions 

We have described the purpose of key escrow schemes and certain fundamental 
properties which such schemes are likely to need to satisfy. We have consid- 
ered how we might adapt conventional key management schemes to provide key 
escrow and key recovery services. We have observed that, in an international 
escrow context, whilst adapting symmetric cryptography based key manage- 
ment schemes results in potentially usable mechanisms, using a conventional 
certificate-based key distribution infrastructure (based on asymmetric crypto- 
graphy) is not really appropriate. This latter observation, combined with a desire 
to avoid some of the network bottle-neck problems associated with symmetric 
key management methods, led us to a description of a family of technical solu- 
tions based on use of the Difhe-Hellman key agreement scheme. These solutions, 
which are all variants of the RH scheme, have certain advantages over the sym- 
metric cryptography schemes, although in some cases these advantages may not 
be terribly significant. 

We have not attempted to provide an exhaustive list of all proposed mecha- 
nisms; there are by now a large number of such mechanisms, designed to meet 
a range of possible user requirements. For a list of mechanisms the interested 
reader is referred to the excellent survey by Denning and Branstad, |S|. It is 
likely that new mechanisms will continue to be devised, particularly given that 
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the operational use of these schemes is likely to grow rapidly in the next few 
years. 

Finally, if key escrow is to become a useful part of the secure networks of 
the future, then one major challenge will be to integrate key escrow techniques 
into secure network protocols (e.g. SSL and Secure IP) and secure distributed 
applications (e.g. MOSS and Internet Payment Protocols). 
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Abstract. Smart cards play an increasing role as 'active' security devices. Due 
to its microcomputer and programmable memory, a smart card can cater for the 
specific needs of the environment it is used in. Smart cards allow the secure 
handling and storage of sensitive data such as user privileges and cryptographic 
keys as well as the execution of cryptographic algorithms. They are secure 
tokens by means of which a user can be identified and authenticate a computer 
system or communication network and vice versa. This paper provides a 
comprehensive introduction into the features of chip cards, the principals of 
their operating system, their life-cycle and the standards governing them. It also 
includes a brief discussion of major applications and an outlook on the future 
development. 



1 Introduction 

"Smart Cards. The ultimate personal computer." is the title of a book by J. Svigals 
[15] one of the first treatise of this subject. Since its publication in 1985 smart cards 
have gone a long way towards achieving this claim. What are smart cards? Smart 
cards are a specific type of chip cards. These are cards, usually made of plastic, 
containing a chip. Depending on the properties and features of this chip and its 
'carrier' we distinguish the following types, which we will discuss briefly to achieve a 
common understanding of the terminology. 

Memory cards contain non-volatile memory and allow 'free' reading and, in many 
instances, writing or updating of data stored. Writing usually refers to changing a 0- 
bit/byte to a 1-bit/byte (or vice versa), while updating is erasing the contents of the 
memory cells followed by writing. Such cards are used instead of magnetic stripe 
cards as they are more reliable and offer far more memory. Not all types of memory 
allow the erasure of data, a feature which is a basic requirement in many applications. 

Intelligent memory cards contain a security logic in addition to the non-volatile 
memory. This allows the introduction of security attributes for reading and writing 
data. A memory zone may be secret (the data is used for card internal purposes only), 
public or sensitive. The latter means that it is accessible only after the presentation of 

B. Preneel, V. Rijmen (Eds.): COSIC'97 Course, LNCS 1528, pp. 307-331, 1998. 
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a correct "personal feature" of the user. This is in most cases a Personal Identification 
Number (PIN) consisting of 4 to 8 digits. The PIN is protected against trial and error 
attacks by a 'false-presentation-counter'. After a specified number of consecutive false 
entries the security logic blocks the non-public data against any further access. The 
new generation of telecommunication chips (for pre-paid telephone applications) also 
include hardware algorithms for challenge-response mechanisms for the 
authentication of the card by the system to increase the security against cloning. 

Smart cards are chip cards where the chip is a microcomputer with programmable 
memory. 

Super smart cards are smart cards with an integrated key board, a display and solar 
cells or a battery. Due to its complexity and high price, this type of card has not 
advanced much beyond field trials. 

A contactless card can be any of the above. Its name is derived from the way the 
data is transmitted between the chip and the InterFace Device (IFD) or the Card 
Accepting Device (CAD); the standardised names for chip card readers. In the last 
three years the standardisation of such cards has made enormous progress (see 
chapter 6 below). 

Hybrid cards usually refer to chip cards which have two or more interfaces. Such 
an interface can be a magnetic stripe, contacts, contactless, or an optical memory. 
Most present-day chip cards use contacts for the transmission of power and data. 



2 Interfaces and Dimensions 

In this chapter we discuss the interfaces and the dimensions of chip cards or 
integrated circuit(s) cards (IC cards) with contacts. The dimensions and locations of 
their contacts are laid down in Part 2 of the International Standard ISO/IEC 7816. 
This standard [11], which is jointly published by the International Organization for 
Standardization (ISO) and the International Electrotechnical Commission (lEC), is 
the basic reference for such cards. 

In addition to the eight contacts, the card can be equipped with a magnetic stripe or 
be embossed. Embossing and magnetic stripe shall be on opposite sides. The reader is 
referred to references [9], [10] and [11-2] for details of the specifications of these two 
features. While the current version of ISO/IEC 7816-2 allows contacts and magnetic 
stripe to be on the same side, this possibility has been excluded in the revision of this 
standard which is expected to be published later this year. Figure 1 below thus shows 
the only possibility for a card which provides all three interfaces. Such cards are 
typically cobranding cards comprising, for instance, a credit card and a 
telecommunication function. 
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2.1 Dimensions 

The 'standard' identification card or ID-1 card [8] is the size of a credit card. Figure 
2 gives the approximate dimensions of this card and the location of contacts as well as 
height and width of the so called Plug-in card. This ID-000 card with a height of 15 
mm and a width of 25 mm has first been specified by the European 
Telecommunications Standards Institute (ETSI) for GSM, the Global System for 
Mobile communications, where about half the number of cards have this format [5]. 
They are mainly used in mobile phones which are too small to accept an ID-1 card. 




10 mm 



^ H20 mm 


85,6 mm 







Fig. 2. Dimensions 

A third type, the so-called "Mini Card" or ID-00 card is 66 mm in width and 33 
mm in height [1]. It has the same location of contacts with respect to the upper and 
the left edge as the ID-1 card. This allows the same card reader, if so designed, to 
accept either card. Both new formats can be thought of as obtained from an ID- 1 card 
by cutting away excessive plastic. 
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2.2 Electrical Interface 

Figure 3 shows a layout for a contact area providing all 8 contacts Cl to C8 
specified in [11-2] (the logo of the card manufacturer is etched into the surface). The 
contacts C4 and C8 are reserved for future use by ISO/IEC and are often not 
provided. 

The supply voltage Vcc is specified as 5 V ± 10% in [5]. GSM also specified a 3 
Volt interface to improve battery life and thus stand-by and operation times of mobile 
phones [6]. Both properties have been incorporated in the revision of ISO/IEC 7816-3 
[11-3]. Development within GSM has already started on mobile phones using an even 
lower voltage than 3 V. This will also be reflected on a new standard for GSM cards 
operating at 1.8 V and lower. ISO/IEC has also approved a new work item 
standardising low voltage interface on a general level. One of the major problems 
facing such specification is the task of achieving backwards compatibility between 
"new" and "old" phones and "old" and "new" cards. Dual voltage cards supporting 1.8 
V and 3 V will most certainly not work at 5 V and may, if no precautions are taken, 
even be destroyed. It is expected that chips which require only 1.8 V at the interface 
will be available around the turn of the millennium. 

Contact C2 is used for the reset signal of the card. The baudrate for the answer to 
reset (ATR) is equal to the frequency supplied on contact C3 divided by 372. The 
divisor of 372 is due to a quartz commonly used to drive the chip and which supplies 
about 3.57 MHz resulting in a baudrate of 9600 bits/sec. During the ATR the baudrate 
can (within certain limits) be increased or decreased for the subsequent 
communication. It is also possible to change other transmission parameters or to 
select a protocol with different features to the default protocol known as T=0 (see 
paragraph 3.2). During reset the chip shall support 1-5 MHz. 
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Fig. 3. Contact layout and assignment of the contacts 
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Contact C6 is used to supply the programming voltage Vpp for the non-volatile 
memory. An external programming voltage is needed if the chip has no internal 
charge pump to derive it from the supply voltage. The change from EPROM to 
EEPROM technology (see below) during the last years is the reason that contact C6 is 
no longer used. 

Contact C7 is the only port for the transmission of data. 



3 Performance 

The performance of a smart card depends to a great extent on the chip and the 
protocol run between the card and the interface device. 



3.1 The Microcomputer 

Bearing in mind, the thickness of the card (0.76 ± 0.08 mm [8]) and the torsion and 
bending it will be subjected to during its life, only special purpose chips can be used. 
Today's microcomputers are single chip solutions which means that all the parts 
shown in figure 4 are integrated onto a single piece of silicon. This has some obvious 
advantages from the points of embedding, reliability and security. Connecting the 
chip to the contact area (the bonding of the chip) and embedding this module (or 
stamp) into the plastic carrier is a specialised profession. 



CPU 



^ 1 / 0 - 
Port 



AU 



RAM 

ROM 



EPROM 

or 

EEPROM 



Fig. 4. A smart card microcomputer 

The Central Processing Unit (CPU) comprises an 8 bit controller and is in most 
instances a variant of a 6805 (e.g. Motorola, SGS-Thomson), a 8051 processor (e.g. 
Philips, Siemens) or a manufacturer specific CPU (e.g. Hitachi). As memory is 
sparse, programming is usually done in assembler taking into account the specific 
properties of the CPU, its instruction set and the available memory. As an example let 
us consider the Data Encryption Standard (DES) [2] which is often used for message 
or entity authentication (i.e. the authentication of the card to the system or vice versa). 
This algorithm requires approximately 800 bytes of memory, giving a processing 
time of about 10 msec at 5 MHz for a 64 bit block. In the last few years the 
programming language C is often used if the application does not require too much 
memory (the overhead of programming in C is estimated at 30 %). It should be noted 
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that many card manufacturer, who in most cases also do the software development, 
have their own operating system(s). 

The Read Only Memory (ROM) is mask programmed. The photographic mask 
containing the customer specific ROM code is one of several layers used in the 
production process of the chip (see [13] for details). This has some important 
consequences for the design and the quality control of the software. The ROM code 
should only contain programs and data which are not specific to a card but are the 
same for a large number of cards and which are constant during the life of the card. A 
change of the ROM code requires a new mask. It takes several months from the 
completion of the software to the first die becoming available. 

The ROM code typically contains the operating system of the card, the 
transmission protocol(s) and commands, the security algorithms and the software for 
the application. The card specific (secret) keys needed for the execution of the 
security functions are contained in the non-volatile memory. 

The Random Access Memory (RAM) is a volatile memory the contents of which 
are lost when the power supply is switched off. It is used by the CPU as a buffer for 
storing transmission data and as a very fast access memory for the intermediate 
results (workspace) produced during the execution of an algorithm. Reading or 
writing a byte takes a few microseconds, which is a magnitude of 1,000 times faster 
than writing a byte into the (E)EPROM. 

The non-volatile programmable memory of present-day cards consists of 
Electrically Erasable Programmable Read Only Memory (EEPROM). This type of 
memory allows a minimum of 100.000 update (i.e. erase/write) cycles. They derive 
internally the required programming voltage of about 18 V from the supply voltage 
Vcc. First generation smart cards had Erasable Programmable ROM (EPROM) with 
an external source for the programming voltage Vpp. As the contents of the EPROM 
can only be erased by UV light, every cell can be programmed just once by the CPU. 
The use of EPROM cards was thus limited to applications which do not require a 
frequent update of the memory. 

One important boundary condition is the surface area of the chip which should not 
exceed 25 square millimetres. This and the present day technology (0.6 to 1.2 pm 
HCMOS) explain the size of the memory available for smart card chips (table 1). 



Memory 


typical 


maximum 


factor chip area 


ROM 


8- IbkByte 


32 kByte 


1 


EEPROM 


2 - 8 kByte 


16 kByte 


4 


RAM 


128 - 256 Byte 


512 - 680 Byte 


16 



Table 1. Memory size 



The "factor" gives a rough estimate for the silicon area used by such a cell of 
memory compared with the area needed for a ROM cell. This explains why RAM is 
sparse. 

New non-volatile technologies such as Flash EEPROM and Ferro Electrical RAM 
(FRAM or FeRAM) will have quite an impact on the performance of smart cards. 
Flash EEPROM uses less area than EEPROM but can only be updated a few thousand 
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times. Flash memory provides a good alternative to ROM, especially for the rapid 
production of application prototypes or different versions of operating systems. 
FRAM is probably the more exciting one because it has a write cycle similar to the 
RAM (200 ns) and maintains stored data for the same duration as EEPROM (up to 10 
years). The features of these three types of non-volatile memory are shown in table 2. 

The non-volatile memory is organised in so-called pages which are physically 
group memory cells. A page usually consists of between 4 and 64 bytes which can 
programmed (write/erase) in "parallel". This substantially reduces the programming 
time. In most cases it is also possible to program a specific byte of a page. 



Technology 


Write/Erase Cycles 


Write / Write-tErase Time 


EEPROM 


0 

1 


1.75ms/3.5 ms 


Elash EEPROM 


10'- 10“ 


1.5ms/3.5ms 


PRAM 


10“ 


200ns 



Table 2. Eeatures of Memory Technologies 



Added Units (AU) provide special functions which could otherwise not be handled 
at all or at least not within an acceptable time. A typical example is a coprocessor in 
the form of extra hardware for the execution of modular arithmetic. This is, for 
instance, needed for the execution of public key algorithms. Other examples of AUs 
are timers. Universal Asynchronous Receiver/Transmitter (UART), Memory 
Management Units (MMU) and hardware security logic. 



3.2 The Transmission 

For the exchange of data between a smart card and an interface device two 
protocols have been standardised [11-3]. They are denoted by T=0 and T=l, 
respectively. Both of them are asynchronous, half duplex protocols. The main 
difference between the two lies in their handling of data and the OSI reference model. 

The character transmission protocol T=0 [11-3] can be characterised as a (byte- 
oriented) protocol of the first generation when computing power and RAM of the 
chips were fairly limited. Checking the parity of a byte immediately after having 
received it and requesting its retransmission is the only error correction. As this can 
not be achieved by 'standard' hardware a special UART is needed in the IFD. There is 
no clear separation of the transport and application layer which, for instance, makes it 
impossible to encrypt the header of a command. Nor is it possible to transmit data in 
both the request and the response of one command. This causes some overhead, for 
instance, during any authentication process, since data has to be exchanged between 
the card and the interface device. A fair amount of overhead is also unavoidable if the 
data to be transmitted is larger than the buffer in the RAM. The data have to be sent 
byte after byte until the buffer can cope with all remaining bytes. These can then be 
requested by using a special acknowledgement for the last byte received prior to this. 

The byte-oriented transmission protocol T=0 is, however, less complex than the 
block protocol T=l. The standardisation of the latter was finalised in 1992. T=1 
respects the OSI (Open System Interconnection) reference model and data may be 
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sent in both a request and the response. As its name suggests, data can be handled 
(and transmitted) in "blocks" and the error check is carried out on a block of data. 



3.3 The Throughput 

Optimising an algorithm for a smart card is an act of balancing speed against 
memory. For the speed of the algorithm is only one of several factors which 
determine the performance of the card. Input, calculation and output are sequential 
operations. Each byte of user data is sandwiched by a start bit preceding it and by a 
parity bit and two stop bits following it. So the transmission of each user byte requires 
the transmission of 12 bits. This yields a throughput of at most 3200 user bits per 
second at a baudrate of 9.600 bits/sec and an infinitely fast algorithm. This does not 
take into account any overhead caused by the transmission protocol or the buffering 
of data. 

As an example consider the DES, which acts on blocks of 8 bytes. Each block 
requires the transmission of 96 bits which takes 10 msec each way. Table 3 gives 
some (theoretical) values for the throughput of the card depending on the speed of the 
algorithm (given in both msec/DES block and bits/sec). 



algorithm 


40 


20 


10 


5 


msec/block 


algorithm 


1.600 


3.200 


6.400 


12.800 


bits/sec 


smart card 


1.066 


1.600 


2.132 


2.560 


bits/sec 



Table 3. Throughput 



One can see from table 3 that the speed of the algorithm has only a minor effect on 
the throughput once the transmission of a block takes about as much time as the 
calculation. Other means to increase the throughput are a higher baudrate (e.g. 115 
kbit/sec) and the use of only one stop bit, which is possible in T=l. 



4 Smart Card Operating System 

Operating systems are used on different digital hardware platforms - from smart 
cards, pocket calculators to organisers, PCs and mainframes. Broadly speaking, the 
term operating system, for which there is no general definition, refers to a group of 
system programs required for operating a computer. 

The operating system provides defined functions to the user, who in turn need not 
know anything about the computer hardware. The user can run and program 
applications almost completely independently of the hardware. The operating system 
takes care of controlling and organising memory media (RAM, hard disks, CDs, etc.) 
and of programming processors. It allows the hardware manufacturer to incorporate 
many technological developments without there being a need to change functions of 
the operating system. 
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What has been said about operating systems for "large-scale" computers also 
applies to operating systems for smart cards, the ultimate personal computer. A smart 
card operating system and its basic tasks can be characterised as follows: 

• miniature operating systems requiring memory capacity of a few kBytes; 

• administration of security hardware based on single-chip microcontrollers; 

• single processing systems; 

• machine-interfaces in the form of a serial interface; 

• secure data storage; 

• support of cryptographic methods for authenticating system components 
and enciphering/ deciphering data; 

• provision of IT-security for applications. 

The operating system and the smart card hardware have to protect themselves 
against the following three basic threats for the duration of their entire life cycle (see 
4.4 below): 

• loss of confidentiality by spoofing or unauthorised information about 
programs and data such as keys, PINs and user data; 

• loss of integrity by manipulation or unauthorised modification of 
information such as identification number and counters of electronic 
purses; 

• loss of availability by unauthorised withholding of information or system 
functions. 



4.1 Software Standardisation 

The basis for all industry specifications and thus the most important smart card 
standard is "ISO/IEC 7816, Identification cards - Integrated circuit(s) cards with 
contacts" [11]. The following list describes the major topics of some parts of this 
International Standard which are relevant for smart card operating systems: 

• ISO/IEC 7816-3: Transport protocols T=0 and T=l; 

• ISO/IEC 7816-4: File organisation, commands, historical bytes and secure 
messaging; 

• ISO/IEC 7816-5: Definition and registration of the Application IDentifier 
(AID); 

• ISO/IEC 7816-6: Definition of data objects; 

• ISO/IEC 7816-7 (Draft): Commands for Structured Card Query Language 
(SCQL) for database application; 

• ISO/IEC 7816-8 (Draft): Security functions for Public key procedures and 
extended PIN functions; 

• ISO/IEC 7816-9 (Draft): Personalisation commands and extended file 
handling commands; 

• ISO/IEC 7816-11 (Draft): Access conditions and security attributes. 

Even if smart card operating systems have been implemented in accordance with 
these International Standards, it does not mean that they are compatible with each 
other. This is to some extent due to the options provided for in the standards. 
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Specifications are thus required to select particular items from the standard to 
implement compatible smart card operating systems (of different manufacturers) for 
one and the same application. One such specification is GSM 11.11. Furthermore, 
some applications as, for instance, electronic purses require functionality not defined 
in ISO/IEC 7816. They need, therefore, "private-use-commands". Today, 
approximately 60 % of the functions of a smart card operating system are private use. 
In 1994 the leading credit card organisations EUROPAY, MasterCard and VISA 
(EMV) began to draft a specification for smart cards in international payment systems 
based on ISO/IEC 7816. In June 1996, version 3 of the EMV specifications has been 
published [3]. This allows the implementation of the basic command set for 
compatible credit card systems based on smart cards. 



4.2 Structure of Smart Card Operating Systems 

The flow of information between an interface device and a smart card occurs via 
transport protocols in the form of command-response pairs. In most cases the 
interface device or the application (terminal, PC, etc.) has the role of the master, i.e. 
the commands will be generated and processed by the IFD. In those cases, where the 
smart card represents the application (e.g. in the case of security modules or in 
specific applications within the GSM SIM Application Toolkit [7]), the roles may be 
reversed (see figure 5). 



Master 


Command 


Slave 


IFD 




ICC 


(ICC) 


◄ 


(IFD) 




Response 





Fig. 5. Information transaction 

In accordance with the OSI 7-layer model the information transaction can be 
divided into three protocol sections: 

• physical layer (layer 1); 

• data transmission protocols (layer 2); 

• information protocols, for command and response data (layer 7). 

Smart card operating systems are divided into modular functional units called 
managers - just like computer operating systems. According to reference [18] an 
information transaction may run through the following managers (see figure 6): 

• The Transport Manager controls and secures the data transmission using 
asynchronous, half duplex transport protocols. These can be the already 
mentioned protocols (T=0, T=l) or a national protocol (all national 
protocols no matter how different they may be are denoted by T=14). 

• The Secure Messaging Manager covers the cryptographic protection of the 
transmission by enciphering or deciphering information and/or by checking 
information for authenticity. 



Smart Cards - Requirements, Properties, and Applications 



317 



• The Logical Channel Manager is required for accessing an application if 
several applications are "open" simultaneously. This semi-multitasking is 
required, for example, in the case of a bank application transferring money 
to an electronic purse. 

• The Command Manager verifies command syntax. In some operating 
systems it also controls the command processing protocol by using the 
state machine(s) of an application. 

• The Security Manager is in charge of object access control, in particular 
for keys. It controls, for instance, the states of the state machine which are 
depending on the successful or unsuccessful execution of the identification 
of the user and of the authentication mechanisms. 

• The File Manager administers the different file categories and supports the 
different file types. 

• The Memory Manager administers the entire memory organisation, e.g. 
installation, applications and files. It calculates checksums, repairs 
defective file structures and takes care of the administration of the 
available memory. 

• Functions. Among these are, for example, mathematical operations for 
specific cryptographic functions. In some chips they are supported by 
hardware. These functions may be part of the whole system or just part of 
one or more applications. 

The smart card operating systems of the STARCOS® family (Smart Card Chip 
Operating System) [14] incorporate these managers as part of the system concept. 
Since these universal, application-independent operating systems offer structured 
administration they are suitable for administering several applications and issuers on 
one card. 




Fig. 6. Structure of a smart card operating system 
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4.2.1 File Organisation 

A smart card operating system administers files in directories - similar to 
conventional PC operating systems. One distinguishes the following components 
within the file organisation which one can visualise as having a "tree-structure" 
(figure 7): 

• Master File (MF): the root of the file system (tree); 

• Dedicated Files (DF): a DF contains substructures and the actual 
application (DFs are also called "directories"); 

• Elementary Files (EF): an EF contains application information or data. 

The MF is usually selected implicitly after the card has been reset. It may also 
contain an application, for instance on a mono-application card. In the case of 
multiapplication cards each application is contained in a separate dedicated file or in 
further subdirectories. An application is selected by using an application identifier 
(AID), which can be registered on both international and national level with ISO/IEC 
[11-5], or by a (fixed) file identifier consisting of two bytes. Application identifiers 
have the advantage that the interface device does not have to know the file identifier 
for the application and that, as a registered AID (a so-called RID) is unique world- 
wide, several applications can easily be combined on a card. In the case of (fixed) file 
identifiers a collision can arise if two applications which use the same file identifier 
are to be combined on one card. Data which is used for all applications in the card 
(for example administrative and general security information such as serial number, 
keys, PIN) and data concerning the administration of the card life cycle are stored in 
the master file. This information is, for instance, used by the operating system for the 
creation of a new application. Application specific control information and files are 
stored in a DF containing the application. They are separated logically and, in some 
cases, physically from other applications contained in different DFs. The 
administration of rights for DFs arranged in a "vertical" structure is always performed 
by the "parent" DF i.e., the DF which resides "one level up". A dedicated file can 
administer several dedicated files which are "one level below". An example would be 
a financial card where the same service provider is responsible for a payment 
transaction application and credit, debit and electronic purse functions. 

ISO/IEC 7816-4 [11-4] distinguishes two categories of Elementary Eiles (EFs). 
While the data contained in a Working Elementary File (WEF) cannot be interpreted 
by the operating system, the data stored in a Secret File (ISF) must be interpreted by 
the operating system. A DF may contain more than one WEF but only one ISF. 
Typical information stored in an ISF are keys which are to be protected from read by 
the outside world. Smart card operating systems such as STARCOS® may, in 
addition, support files which are of "mixed" type, i.e. some of their data can be 
interpreted while the remaining data cannot be interpreted by the operating system. 
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4.2.2 File Structures 

The structure of an EF depends on its use. The following four types are defined in 
ISO/IEC 7816-4 [11-4]: 

• transparent files consisting of a sequence of bytes having an amorphous 
structure; 

• linear fixed files consisting of records having the same length; 

• linear variable files consisting of records of variable length; 

• cyclic files having records of fixed length which are organised in a ring 
structure, the oldest entry will be overwritten by the entry to be stored. 

The four basic structures can be extended by other file structures. Examples are 
database applications (database files), electronic purses (compute files) or public key 
applications (internal public key files). 



linear fixed 



linear variable 




cyclic 



transparent 



Fig. 8. Data structures of elementary files 

The definition of the category, the type and the access possibilities (read, write, 
update, delete,...) with their respective access conditions (never, always, PIN, special 
authentication,...) are stored in the file header of each file. 
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4.2.3 Commands 

The functionality of an operating system is not only reflected in the number of 
available commands but also in their complexity. This grows with the need for more 
security for an application. The commands defined in ISO/IEC 7816-4 [11-4] are the 
basic command set and can be grouped in the following functional classes: 

• file selection; 

• read data; 

• modify and delete data; 

• generate data; 

• compare data; 

• authenticate using cryptographic functions. 

Due to the complexity of today's applications approximately 60% of the 
commands of an operating system are "private-use-commands" and not defined in 
[11-4]. Examples are commands for mutual authentication and cryptographically 
secured counter functions representing chained basic functions, so-called macros. 



4.3 Security 

Operating systems quite often administer applications with high security 
requirements. The security of a smart card is a combination of the security of the chip 
(hardware) and the operating system (software). To obtain optimum security the 
programming of an operating system requires extensive knowledge of the properties 
of the hardware in particular with respect to electrical characteristics, detectors, 
interrupts, timing and other features which may influence the security. From a 
software point of view one can distinguish between functional security and security 
against manipulations. 

Functional security can be guaranteed by: 

• transport protocol; 

• command interpreter; 

• file organisation, file structure, data objects; 

• functions; 

• layer separation; 

• error detection and correction functions. 

Security against manipulation can be obtained by implementing: 

• secure messaging; 

• identification and authentication; 

• state machines; 

• object protection; 

• digital signature; 

• proof retention; 

• random numbers generators. 
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4.4 Card Life Cycle 

The operating system contributes considerably to the guaranteed card life cycle of 
a smart card. The card life cycle - from production to deactivation of the card (see 
figure 9) - is divided into the following five phases according to ISO 10202-1 [12]: 

• Phase 1 - chip and card manufacturing 

development of the operating system and transport to chip 
manufacturer; 

implementation of the operating system, usually as a ROM mask; 
chip production and transport to card manufacturer. 

• Phase 2 - card preparation 

initialisation and prepersonalisation of the card, i.e. loading constants 
and system-related data; 
dispatching the cards to the issuers. 

• Phase 3 - application preparation 

assignment, personalisation and activation of one or several 
applications. 

• Phase 4 - application phase 

using global card functions and application access; 

using management functions (administration) of applications (lock, 

release). 

• Phase 5 - termination of use 

delete keys and the complete application. 




Fig. 9. Card life cycle 
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5 Applications 

The main security functions of a smart card are the identification of the user, the 
authentication of the card by the system and, depending on the application, the 
authentication of the system by the card. This involves the secure storing of secret 
information as well as the secure execution of cryptographic algorithms. 

The identification of a user is usually done by means of a Personal Identification 
Number (PIN). The PIN is verified by the microcomputer of the card which compares 
in its RAM the PIN presented with the PIN stored. If the comparison is negative, the 
CPU will refuse to work. The chip also keeps track of the number of consecutive 
wrong PIN entries. If this number reaches a pre-set (card specific) threshold (usually 
three), the card blocks itself against any further use. The change of the PIN by the 
user, which is a standard feature of smart cards, may be subjected to the exclusion of 
trivial values such as "0000", "123456", "4711", "0815" or the date of birth of the 
user (if known) which could be stored in the card. 

At the beginning of any session is authentication, the "corroboration that an entity 
is the one claimed" (ISO/IEC 9798-1). Entity authentication is achieved by using a 
"challenge-response method" employing a cryptographic algorithm such as the DES 
or a public key function. To authenticate the card the system challenges the card by 
sending a random number. The card uses this and its own card specific key as input to 
its cryptographic algorithm. The output of the calculation, the response, is transmitted 
to the system. This compares the value received with the one calculated itself. If the 
two match the card is considered to be genuine. Analogously the card can check the 
authenticity of the system. 



5.1 GSM 

The Global System for Mobile communications (GSM) is a digital, cellular radio 
system with more than 170 networks on air in about 100 countries. Access to all these 
networks is controlled by smart cards, the so-called Subscriber Identity Modules 
(SIMs), in form of ID-1 or Plug-in cards. GSM is the first world-wide application 
based on smart cards and has given a huge impetus to their standardisation and use. 

Subject only to their size and roaming agreements between the network operators 
all SIMs work in all mobile phones in all networks. The general properties of the 
interface between the SIM and the mobile phone are laid down in GSM 11.11 [5] 
while GSM 11.12 [6] was the first specification for a 3V card interface. The latest 
specification is GSM 11.14 [7] the so-called SIM Application Toolkit. This provides 
the operators with a toolbox to create their own applications on the card. Information 
containing commands and data may be downloaded over the air into the SIM, 
transparently to the mobile phone. After interpreting the information, the SIM will 
react as requested by, for instance, updating a file or creating a new file or even a new 
application. The SIM may also become pro-active and request the mobile phone to act 
on its behalf. For more information on GSM and SIMs the reader is referred to [16]. 
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5.2 Company ID-Cards 

Using a smart card as a company ID-card and, at the same time, for access control 
to the company computer network can solve quite a few security and handling 
problems arising from passwords and access control in general. 

The communication between the card and the system can be protected by message 
authentication codes to secure the update of sensitive data in the card. The 
combination of a smart (company) card with PIN has several advantages over 
Password and User-ID. Access to the network requires the possession of the card and 
the knowledge of the PIN. Knowing just the PIN is not sufficient. If the holder 
"lends" the card to someone else this will be temporary. Without the card the holder 
may not be able to leave or enter the premises or parts thereof. Passwords can be 
passed on indiscriminately; company cards will not. A proper log-off can be enforced 
by making the entry to the (computer) room depend on the card and by checking the 
presence of the card, creating security entries if the card is forcefully removed. 

To enhance the security, visual information can be engraved into the card body for 
example by means of a laser beam. This information could consist of the usual data 
such as date of issue and card number as well as typical data of an ID-card such as the 
photograph and the signature of the card holder. 



5.3 Banking Cards 

The first nation-wide smart card application was a banking card in France. The 
field-test using memory chips took place in Lyon in 1983. Shortly afterwards 
microcontrollers from Motorola with EPROM as non-volatile memory were 
introduced at national level. The transition from magnetic stripe to microcontroller 
with on-board memory had the following advantages from a security point of view: 

• administration, storage and validity check of the PIN by and in the chip; 

• authentication and enciphering of data using a cryptographic algorithm. 

Smart cards supporting electronic purse applications were introduced on a national 

level in Austria in 1995 and in Germany in 1996. All these cards, which were issued 
as a replacement for the eurocheque cards with magnetic stripe, were hybrid cards 
with both a magnetic stripe and a microcomputer. Apart from the usual Point of Sale 
(POS) functions of the magnetic stripe the chip supports an electronic purse. Since the 
credit limit is also administered by the chip POS transactions can now be handled off- 
line. As in most electronic purse systems (e.g. Proton, VISA Cash, STARCOIN) the 
loading of the purse is done on-line while purchasing can be done off-line. With the 
availability of on-board hardware units for special arithmetic the symmetric 
cryptoalgorithms such as DES are expected to be replaced with asymmetric (public 
key) algorithms in the coming few years. This will significantly improve both the key 
management and the cryptographic protection. 
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5.4 Other Applications 

Not only banking cards will benefit from the introduction of digital signatures and 
authentication mechanisms using public key based cryptosystems. The recent 
development of such systems and the improvement of the added hardware units now 
allow the computation of a digital signature employing a key of 512 to 1024 bits in 
much less than 1 second. This is of particular importance for the security of 
information and transactions for applications in world-wide network. 

Contactless cards are supposed to be ideal for applications where the cards of a 
large number of people may have to be handled in a very short time. A typical 
example is a "city card" with an electronic purse for the combined use of (public) 
transport and public amenities such as libraries, swimming pools and museums. An 
example of a hybrid card in both meanings of this term is the Lufthansa chip card. Its 
magnetic stripe (and embossing) serve as a credit card, its contactless microcontroller 
chip is used for electronic ticketing and hoarding, and the memory chip with contacts 
as a subscriber card for the public German telephone system. 

Another large application are the so-called health cards which may contain a 
database of the medical history, allergies and other relevant information such as 
address and insurance number of the card holder. Access and update rights depend 
very much on the data and may be divided between the patient and the respective 
medical doctors. Access is defined on the level of data objects and not on files. A 
surgeon, for instance, may thus only access data relevant for the diagnosis and 
treatment of cancer. 



6 Standardisation 

Though chip cards are quite standardised objects this does not mean that there is 
nothing left to do. Conformance testing and common test methods are one subject. A 
standard, solely dedicated to test methods, is ISO/IEC 10373 (1993). This is one of 
the many topics within the scope of SC 17, a subcommittee of the Joint Technical 
Committee 1 (Information technology) of ISO and lEC. SC 17 is also responsible for 
the International Standard ISO/IEC 7816 and other basic International Standards for 
identification cards. One of its Working Groups (WG) develops a multipart standard 
for contactless cards ISO/IEC 10536. The first three parts of this standard correspond 
to the respective parts of ISO/IEC 7816. The work on proximity contactless cards 
(ISO/IEC 14443) has just started. 

Another international standardisation body dealing with smart cards is ISO/TC 68 
"Banking and related financial services". It edits two multipart standards: Messages 
between the integrated circuit card and the card accepting device (ISO 9992) and 
Security architectures of financial transaction systems using integrated circuit cards 
(ISO 10202). 

Within Europe chip cards are standardised by CEN, the Comite Europeen de 
Normalisation, and by ETSI, the European Telecommunications Standards Institute. 
The Technical Committee TC 224 of CEN has 13 working groups which specify 
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items from physical characteristics (WG 1) to airline applications (WG 14). Its WG 9 
was closely related to the former ETSI SubTechnical Committee STC TE9 which 
produced a standard on application independent card requirements for 
telecommunications [4]. This specified for the first time commands which went 
beyond the basic erase, read, write and update functions. This is now to a large extent 
superseded by part 4 and the draft versions of parts 7 and 8 of ISO/lEC 7816. WG 10 
of TC 224 develops standards for electronic purse systems. ETSI produced several 
smart card specifications for specific applications. The most important ones are 
probably those written for GSM. Others are the DECT Authentication Module 
(DAM) specification for the Digital Enhanced Cordless Telecommunications and its 
test specification. ETSI has now formed a new Technical Committee to write a 
generic core specification for telecommunication cards. 

More information on the committees mentioned can be obtained from the national 
standards institute of the relevant country. 

Apart from the standards produced and developed by regional and international 
standards organisations there exist quite a few "industry standards". The most 
important one of these is the so-called EMV-specification for payment systems which 
has been written jointly by EUROPAY, MasterCard and VISA [3]. The three parts 
define the IC Cards, the card terminal and the card application. 



7 Outlook 

The advancement of the semiconductor technology in the last years had a dramatic 
effect on the memory provided by smart card chips. While 5 years ago chips 
providing 8 kByte of ROM, 128 Byte of RAM and 3 kByte of EEPROM were the 
flagships of all manufacturers, it can be assumed that in a few years time 
semiconductor technology will have a characteristic distance below 0.6 m and high 
end microcomputers will have in excess of 64 kByte of ROM and 32 kByte of 
EEPROM. The values given in table 1 as maximum will be part of the typical range 
within the next year. This and the progress of the tools will have a strong influence on 
the development of operating systems and applications. It will become common to 
write most of the ROM code not only in C but also in the form of modular blocks. 
This will immensely improve the portability of the software from one microprocessor 
to another, even if they have "incompatible" CPUs, as well as the design of true 
multiapplication operating systems, which require in excess of 10 kByte of ROM 
without the coding of the application. 

As the applications (to be) supported by a smart card become more and more 
complex, today's CPUs with their CISC (Complex Instruction Set Computer) 
architecture and their 8 bit controllers, which are by comparison with other areas 
quite outdated, need to be improved. Several chip manufacturers have started 
extending the cores of their microcomputers by introducing additional instructions 
and ways of addressing memory as well as higher clock rates (e.g. 10 MHz). This 
upgrading has the advantage that existing software is supported and can easily be 
ported. There is, however, a limit to the improvement of the performance. This can 
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only be achieved on a major scale by replacing the core by a RISC-CPU (Reduced 
Instruction Set Computer). This architecture will, for instance, allow internal 
frequencies of 35 MHz and higher. It will also further the introduction of high level 
languages. Several manufacturers have already announced their intention to introduce 
this architecture which has been widely used in other areas for several years (figure 
10 ). 




16 bits CPU 32 bits 



Fig. 10. Trends of smart card microcontroller 

Larger microcomputers with an improved performance will increase the potential 
for multiapplication cards and the requirement to download applications after the card 
has been issued to the user. When loading a new application into a card several issues 
have to be considered very closely. Is the new application independent of the 
hardware (CPU and memory) of the chip and the implementation of the operating 
system? How does it interact with the resident application(s)? Can security problems 
definitely be excluded? For these reasons the loading of another application with 
executable code needs to be evaluated by the software engineers who are responsible 
for the operating system and the resident applications. To ease this process and to 
achieve the goal of downloading applications into issued cards Memory Management 
Units (MMU) and Interpreter Languages will be used. Memory Management Units 
support the operating system in controlling the memory (firewall function) and allow 
the use of the CPU by the downloaded application with executable code. Existing 
interpreter solutions are mostly proprietary and slow down the execution of 
applications and programs. 

In 1995 SUN Microsystems presented Java, an interpreter language for a large 
variety of microprocessor platforms. It was originally intended for the linkage of set- 
top-boxes, copiers and other electronic consumer goods with a microprocessor. Since 
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Java was provided free of charge on the Internet and was running on such a variety of 
hardware platforms it immediately became the language of the Internet. Java has 
completely realised the concept of object orientation and provides security 
mechanisms which make it suitable also for smart cards. The compiler produces a 
byte code which is interpreted by a virtual machine, the so-called Java Virtual 
Machine (JVM). The functionality of this machine is independent of the processor 
and can, by means of the Java API (Application Program Interface), access the 
operating system of the smart card. It can thus also make use of hardware dependent 
functions such as some security, utility and I/O routines (see figure II). The 
standardisation of the Java byte code, the JVM and the JC (Java Card) API for smart 
card is progressed with great determination by SUN and several smart card 
manufacturers. As with all interpreter solutions Java has, however, an adverse effect 
on the performance of the microprocessor. Several chip manufacturers have 
announced the design of new hardware to support the JVM. These products, which 
will greatly improve the performance, are expected to be available within the next 
couple of years [17]. Complete solutions, i.e. the JVM in hardware (pico Java) for 
smart cards, will probably not be available in this millennium. 
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Fig. 11. Software designer's view 

All present Java implementations on smart cards make use of a two-part Java 
virtual machine (JVM) consisting of an Off-Card JVM in a PC and an On-Card JVM 
on the card itself. The Off-card JVM does the pre-processing of the "JAVA byte- 
code" and, in particular, the class files. This optimisation is needed for the processing 
of the byte code by the CPU of the smart card, since current smart card chips are not 
powerful enough for the efficient execution of the standard JAVA byte code. For this 
reason a standardisation of the downloading interface between the Off-card JVM and 
the On-card JVM is important to avoid the development of proprietary solutions. 
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Fig. 12. Application design with MULTOS 

The other new interpreter operating system is MULTOS which is supported hy 
MasterCard and MONDEX. Similarly to Java, the core of the operating system is an 
interpreter which allows the application to be developed independently of the 
underlying hardware. Applications can be written in the high level language C and are 
then translated with the help of a C-compiler into the interpreter language MEL 
(MULTOS Executable Language). MEL is thus a specified interface for downloading 
software. The MEL code is interpreted by the smart card interpreter using the API 
(see figure 12). The security of MULTOS is expected to satisfy ITSEC E6, the 
highest level of the ITSEC certification. The first application to run on MULTOS is 
probably the electronic purse application from MONDEX. Similarly to Java, 
applications requiring the execution of complex or time critical (security) functions 
will need a special API to provide an acceptable execution time for the application. 
As is the case with all interpreter languages, the widespread use of this language will 
depend on the development of hardware specific for MULTOS. This new hardware 
could be an extension of the CPU with respect to the virtual machine or an additional 
processor dedicated to the specific interpreter. 

Smart cards are also security devices and will take over more and more security 
related functions of the systems they are used in. The introduction of technologies of 
0.6 m and below will not only allow the production of chips providing more 
memory, it will also provide an hitherto unknown protection against potential future 
attacks. Extra hardware for public key cryptography (be it RSA with a key length of 
2084 bit or elliptic curve systems) will provide the means for secure (off-line) 
authentication and digital signatures. Digital Signal Processors (DSP) on-board a 
smart card microprocessor will pave the way for the usage of biometric systems for 
user authentication and may make the PIN obsolete. 

The smart card of the future will be a PC in pocket size with sensors for biometric 
features and a human interface. 
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Glossary 




ATR 


Answer To Reset 


CEN 


Comite Europeen de Normalisation 


CPU 


Central Processing Unit 


DES 


Data Encryption Standard 


DF 


Dedicated File 


EE 


Elementary File 


ETSI 


European Telecommunications Standards Institute 


EEPROM 


Electrically Erasable Programmable ROM 


EPROM 


Electrically Programmable ROM 


FRAM 


Ferro electrical RAM 


GSM 


Global System for Mobile communications 


IC 


Integrated Circuit 


ICC 


Integrated Circuit(s) Card 


lEC 


International Electrotechnical Commission 


IFD 


InterFace Device 


ISF 


Internal Secret File 


ISO 


International Oganization for Standardization 


IVM 


lava Virtual Machine 


MF 


Master File 


OSI 


Open System Interconnect(ion) 


PIN 


Personal Identification Number 


POS 


Point of Sale 


RAM 


Random Access Memory 


ROM 


Read Only Memory 


UART 


Universal Asynchronous Receiver/Transmitter 


WEF 


Working Elementary File 
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1. Introduction 

TNO is the Netherlands Organisation for Applied Scientific Research. Its primary 
tasks are to support trade and industry, the authorities and other groups of the 
community in technological innovation and to assist clients and sponsors in solving 
problems. TNO is a fully independent R&D organisation with a staff of 
approximately 4,000 and an annual turnover of more than US$ 500 million. 

The main features of TNO are: 

• multidisciplinary, 

• practice and market-oriented, 

• independent, 

• possessing unique knowledge and facilities, 

• internationally oriented. 

TNO's research takes place at 15 institutes spread throughout the Netherlands. 
Nearly all scientific fields are covered by these institutes. 

The Centre for Evaluation of Instrumentation and Security Techniques (EIB) is 
part of the TNO Institute of Applied Physics (TPD). 

The security section of the Evaluation Centre is specialised in the evaluation of 
security related systems and products. The evaluations are ranging from intruder and 
fire alarm systems, assessing the possibilities of counterfeiting credit-cards and 
documents, to the study of optical security features like holograms. The evaluation of 
electronic payment systems and their components forms the main part of our security 
activities. This includes assessment of the security aspects of PIN Pads, single chip 
security modules and smart cards. Our projects are carried out for both financial 
institutions and manufacturers of EFT (Electronic Funds Transfer) equipment from 
all over the world. 
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The security aspects of more than 75 different smart card based security systems 
have been investigated by the Evaluation Centre. These investigations comprise of 
physical security aspects (the 'silicon'), logical security aspects (card operating 
systems) and organisational measures (e.g. transport, initialisation) . 



2. Security Evaluations 

Security functions of any system, including smart cards, revolve around the three 
basic security principles: integrity, confidentiality and availability. 



2.1 Card and System Authentication 

The first line of defence in (smart) card authentication are the security features on the 
card itself. The most commonly used techniques used are photographs, signatures, iris 
print (rainbow print), pearl lustre ink, tactile laser engraving, holograms, kinegrams 
etc. These measures depend on human inspection. 

Additional security is provided by measures which link the ‘plastic’ to the chip. In 
general optically readable security features, such as holographic barcodes, unique 
optical patterns, are used for this purpose. An additional reader is often required to 
‘read’ the optical pattern. 

The authentication of both the chip and the system is normally based on a shared 
secret, the cryptographic key. The quality of the authentication relies on the secrecy 
of the cryptographic keys. The security measures of the systems will therefore in 
general be focused on the protection of these cryptographic keys. 



2.2 System Security 

The total security of a system depends on the implementation of three aspects: 

• physical security measures (hardware), 

• logical security measures (software), 

• organisational measures. 

An adequate level of security can only be accomplished if these three aspects are 
combined in such a way that all possible weak aspects are covered. 

In general, weak aspects in the design of security product will emerge at the 
interfaces of physical, logical and organisational measures. A 100% secure product 
cannot be made. There will always be a way to break the system. A system is 
considered to be 'secure' if the chances of breaking the system and the consequences 
of this unauthorised access, e.g. compromising the cryptographic keys or the 
biometric template, are acceptable for the end-user. 
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A security scheme of a system, based on secrecy of the security principles, is in 
general not acceptable for end-users. The security of a cryptographic algorithm must 
be based only on the secrecy of the key(s) and not on the secrecy of the algorithm 
(Kerckhoffs’ principle). 

A generic secure application module, see figure 1, will comprise the following 
elements: 

• a physical barrier, e.g. a metal box, 

• fraud sensors, to detect an attempt to fraud the system, 

• an alarm circuitry; this circuitry must process the information from the fraud 
sensors and act appropriately, 

• memory to store sensitive data, e.g. cryptographic keys, biometric template, 

• software to define the functionality of the system. 




Fig. 1 Generic Secure Application Module 

A smart card is a miniature of the conventional security module, but with a major 
difference: in general, a conventional security module is always powered and the 
security functions will therefore always be active, the smart card is most of the time 
not powered and will therefore not have active fraud detection measures. 
Furthermore, the memory of the smart card, in which the secret information is stored, 
much be non-volatile. Normally, EEPROM is used for this purpose. 
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Fig. 2 Generic smart card 

The Evaluation Centre has developed methods for the evaluation of security 
systems, including smart cards. The main goal of the investigations is to establish the 
level of security of the application. More practically, we find out how much effort it 
takes to reveal the secrets of the systems and what can be done with these secrets. 
Smart cards are an important part in modern security systems, where they often 
function as secure application modules. The security aspects of smart cards can be 
analysed internally and externally. 



3. External Analysis 

In an external analysis we attempt to learn as much as possible of the functionality of 
a card by investigating the physical side effects of this functionality, such as noise, 
emission, power consumption, dataflow etc. These experiments are carried without 
opening the chip (black box approach). External analysis can be very threatening 
from an end-users point of view, as possible attacks revealed by this analysis can 
have a low realisation threshold. Examples of external attacks are the ‘Kocher attack’ 
and the latest ‘Bell-core attack’. A lot of experience and creativity is essential to 
reveal secrets in the chip, if at all possible. The outcome of external analyses strongly 
depends on the application. In general, no direct information is gained from an 
external analysis, but what we learn may be used to develop new attack scenarios. 



4. Internal Analysis 

The methods for an internal analysis require opening of the chip. For most smart 
cards this is not a problem. Several etching techniques, for opening the chip and 
preparing the chip surface have been developed by the Evaluation Centre. 

The most common techniques used for an internal analysis of smart cards are 
probing and SEM analysis. 
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4.1 Probing 

A sub-micron probe station, comprising a microscope and an optically stable platform 
with probe manipulators, is used for these investigations. The smallest probe needles 
have a tip radius of approximately 0.5 micron. Tracks on the chip surface with the 
same dimensions can be tapped. A maximum number of 10 probes can be placed on 
the chip, but this number is in practice strongly dependent on the chip design. 

Two methods of probing are generally used: 

• active probing: inserting information, generally at the databus, e.g. to change the 
sequence of the program, 

• passive probing: reading information, generally from the databus. 



4.2 Scanning Electron Microscope Analysis 

A scanning electron microscope (SEM) can be used in various ways during the 
evaluation process. It is mostly used for surface analysis: e.g. for reverse engineering 
of chip structures. 

The SEM can also be used for visualisation of voltages on the chip surface 
(voltage contrast). With this technique, a thorough understanding of the functionality 
of the chip can he obtained. 

With a special technique (single beam voltage contrast), the SEM can be used for 
passive 'probing' on very small tracks (<0.25 micron). 



4.3 Focused Ion Beam Systems 

New techniques for analysing integrated circuits are being developed constantly. 
One of these new developments is the Eocused Ion Beam system (EIB). The EIB 
proves to be a very useful tool for the attack of integrated circuits. 

A EIB system has three main features: 

View mode 

It is possible to use the EIB system as a surface microscope like a Scanning 
Electron Microscope (SEM) 

Milling mode 

The EIB system can be used as a micro milling device. Depending on the use of 
special gases during etching, very small holes can be cut. Such holes can be made at 
very specific locations and with very great precision. This technique can be used to 
selectively remove material from the chip surface, such as the passivation layer. 
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Deposition mode 

When using specific gases together with the ion beam, metals can be deposited on 
the chip surface. Such metal objects can be used to create e.g. test bondpads for probe 
needles, or as new metal tracks. FIB systems are nowadays common in the 
semiconductor industry. The resolution of these systems is by far sufficient to modify 
all integrated circuits available on the market today and tomorrow. A major concern 
is the availability of these systems. All chip manufacturers use FIB systems for device 
modification during chip design and testing. Also, a large number of commercial 
service laboratories all over the world can be used for this kind of work. 



5. Conclusions 

The security aspects in a design should not be viewed upon as an add-on feature. The 
security thinking must be fully incorporated in the design process and implemented in 
the production. 

Although 100% security can never be accomplished, it is possible to build very 
secure systems using smart cards. An adequate design and implementation of 
combined physical-, logical- and organisational security measures can result in a 
secure product. Most products that fail to fulfil their requirements have security flaws 
at the interface between physical, logical and organisational measures. 
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Abstract. Ecash is a payment system designed and implemented for 
making purchases over open networks such as the Internet. In this paper 
we review the main cryptographic techniques used throughout the ecash 
system. We will focus on security aspects as well as some performance 
related issues. The central notion of an electronic coin is treated in detail, 
and the basic protocols manipulating coins are described. 



1 Introduction 

Behind the scenes, banks, credit card companies, and other financial institutions 
have been processing transactions electronically for several decades now. Two 
important developments are taking place however that will open up the field 
of electronic payment systems to the general public. First, the prospect of elec- 
tronic commerce over the ever-growing Internet is creating a large demand for 
electronic payment methods that can be used over such an open network. Sec- 
ondly, the introduction of nation-wide electronic purse schemes is creating many 
more places and situations where smart cards can be used for cost-effective off- 
line payments. 

In this paper we will describe several aspects of the ecash system, mostly 
security related, and discuss its place among other payment technologies. Ecash 
finds its roots in the work by Chaum (see, e.g., |(lha8dl f(lha9()| 'l. who invented 
the notion of electronic coins as well as the basic protocols for electronic cash. 
Electronic coins possess similar properties as metal coins, among which is the 
unique feature that, due to the use of coins, a payment transaction leaves no trace 
about (the identity of) the payer. Currently, ecash technology (as provided by 
DigiCash, see http : //www . digicash . com for more details) is used by a number 
of banks around the globe. These banks issue ecash to their customers, who can 
then spent it at affiliated merchants on the Internet. 

We will focus on the core protocols that make up the ecash system. For 
brevity, we will not mention all the details and alternative approaches that are 
taken into account in the actual system. We do, however, consider some future ex- 
tensions such as the extension to off-line ecash, where the use of smart cards and 
the Internet are combined into a highly secure and versatile privacy-protecting 
payment system. 



B. Preneel, V. Rijmen (Eds.): COSIC’97 Course, LNCS 1528, pp. 338-12221 1998. 
(c) Springer- Verlag Berlin Heidelberg 1998 
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2 Characteristics of Electronic Payment Systems 

Although more and more consensus is building up as to which properties are re- 
quired of a payment system — and in any case what the properties are supposed 
to mean — we are not going to list and describe these properties in this paper. 
Instead, we take a bottom up approach, and describe some of the basic charac- 
teristics of payment systems. From these characteristics one can then infer the 
possibilities and impossibilities for the numerous combinations, and what their 
impact is on the performance and flexibility of the system. 



Payment by Instruction vs Prepaid Electronic Cash In the so-called 
payment by instruction type of systems, a payer basically orders the bank to move 
some sum of money from its account directly into a payee’s account. Examples 
in this category are credit and debit cards as well as many forms of cheques. The 
moment at which the money is actually moved from the payer’s account into the 
payee’s account depends on the system, but at all times banks and credit card 
companies will try to prevent discrepancies between accounts. 

The central security aspect in these systems is to ensure that only legiti- 
mate account holders are able to issue payment instructions. Of course, digital 
signatures are the solution for doing this over a large, open network such as 
the Internet. Since digital signatures only make sense if there is an infrastruc- 
ture for certifying public keys, a lot of effort is devoted to just this. See, for 
instance, the SET (Secure Electroncic Transaction) proposal, a joint effort by 
MasterCard, VISA, and other influential partners, which specifies a hierarchy 
of certif ication au thorities on top of the payment protocols laid out in the iKP 
system PBCH+95) . 

Prepaid systems are conceptually close to electronic equivalents of cash. Tele- 
phone cards, smart card-based systems, as well as ecash are examples in this 
category. The user’s account is debited as soon as the card or device is reloaded 
with electronic cash. During payments the electronic cash is released again, and 
only then the payee’s account will be credited. In the mean time the issuer keeps 
a float corresponding to the outstanding cash. 

The central security aspect in this type of system is to ensure that cards or 
representations of cash cannot be forged. When forgery happens, the float will 
ultimately be insufficient to credit the payee’s accounts for received payments. 
Of course, it should also be ensured that only legitimate account holders can 
reload cash from their accounts. However, this security aspect is now limited to 
the infrequent withdrawal protocol, and is no part anymore of the more frequent 
payment protocol. 



On-line vs Off-line In the field of electronic payment systems, the notions on- 
line and off-line refer to a specific property of the payment protocol. Although 
the payment protocol is functionally a protocol between two parties (payer and 
payee) many payment systems require that the payee contacts a third party (e.g., 
the bank or the credit-card company acting as an acquirer) before accepting a 
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payment. If that is the case, the system is called an on-line payment system; the 
communication between a payee and its acquirer may be using any communica- 
tion medium (not necessarily the Internet). If such a contact with a third party 
is not required during the payment protocol, the system is called off-line. In an 
off-line system payees are required to contact their acquirer on a regular basis 
for clearing all received payments. 



Secret Key vs Public Key Authentication A basic requirement of a pay- 
ment protocol is that it allows a payee to receive payments from any payer. A 
payment can be seen as some sort of authentication of the payer towards the 
payee (to show that the payment is authentic). The authentication can be based 
on secret key cryptography or on public key cryptography. In the latter case, the 
payee only needs to dispose of a public key in order to verify incoming payments. 
Although the costs of equipping smart cards with crypto co-processors are ex- 
pected to become marginal, it is important to note that the property of public 
verifiability can be obtained using simple smart cards only, provided one applies 
a method of what we call signature transport. In such a system, signatures are 
created by the issuer only, and later endorsed by the payer during the payment 
protocol, depending on a challenge from the payee. The trick is to achieve that 
sufficiently many payments can be made between successive reloads, which re- 
quires optimal use of the limited amount of EEPROM available on simple smart 
cards. 

In the case authentication is based on secret key (symmetric) cryptography, 
however, the payer and the payee must dispose of a shared secret key in order 
to complete a payment. A straightforward solution is to give all users the same 
secret key, but this is generally considered insecure, as this would mean that 
breaking a single smart card (i.e., extracting its secret key) will suffice to break 
the complete system. The standard solution is therefore to break the symmetry 
between payers and payees by equipping the merchants with a highly secure 
tamper-proof box called a SAM that contains a masterkey. The payers’ keys are 
derived from this master key in a process called diversification by applying a 
cryptographic hash (e.g., SHA-1) to the concatenation of the master key and 
the payer’s card number. The idea is that the SAM is more difficult to break 
than a smart card, and also that it is possible to routinely check (as part of 
the maintenance) if the SAMs have not been tampered with. A compromise is 
the use of RSA certificates in the EMV standard. Each card carries a fixed RSA 
certificate to show the validity of the card number. At the start of each payment, 
the certificate can be verified against the public key stored in the POS terminal. 
The remainder of the payment protocol again relies on a secret master key stored 
in the SAM of the POS terminal. 



Counters vs Coins The most direct way of representing electronic cash is to 
use a counter stored on a smart card. Clearly, this is a very efficient and flexible 
method, and any amount can be paid from the card as long as it does not exceed 
the value of the counter. A more involved way is to represent electronic cash by 




Security Aspects of the Ecash^^ Payment System 341 



a set of electronic coins. As with ordinary coins, each electronic coin has a fixed 
denomination. Now, any amount can be paid as long as it can be obtained as a 
sum of the denominations of a subset of the available coins. Hence it is possible 
that a certain amount cannot be paid using the available coins although the total 
value of the coins is larger than the required amount. In practice this problem 
is alleviated by choosing a suitable distribution of the coin denominations upon 
reloading, possibly as a function of the expected spending pattern. 

The CAFE project (see, e.g., EBC+Qdl l relies on a compromise between 
these two basic methods. For each payment the required amount is debited from 
a counter but at the same time one special coin is used up. The special coins have 
no value by itself. Upon reloading the counter is credited with the withdrawn 
amount and the supply of special coins is replenished. 

As we will explain later on in this paper, an important property that sepa- 
rates coins from counters is that electronic coins are the only way to achieve a 
system that is secure (in the bank’s interest) and at the same time protects the 
users’ privacy in a strong sense. Another argument that indicates a separation 
between coin-based and counter-based systems is given by the following scenario. 
Consider an off-line payment system that is capable of determining “after the 
fact” which cards have been broken in case a fraud is detected. Suppose that 
for this reason an attacker decides to work with stolen cards. Now, if the system 
relies on a counter, it is no problem if the stolen cards are empty: the attacker 
only needs to manipulate the counter (e.g., set its most significant bit to 1) and 
may then start spending right away. For a coin system, however, it depends on 
how many coins the stolen cards contain: if the cards are completely empty the 
attack will fail completely, and in any case the attacker is limited to using the 
coins that were present at the time the cards were stolen. Furthermore, since 
payees can be instructed not to accept the same coin twice, the attacker can be 
forced to visit different shops in order to be successful. 



3 Money Flow 

We briefly describe the money flow in the ecash system. Where appropriate we 
will distinguish between the ecash bank (or issuer/acquirer) and the ecash mint. 
The mint is the component of the ecash system where coins are created and where 
the databases of spent coins are held. So-called ecash accounts form the interface 
between the bank and the mint. In practice, several ways will be provided to 
transfer money to and from an ecash account. For example, an ecash issuer may 
provide a home-banking application that allows its customers to move money 
between their bank accounts and their ecash accounts. Another possibility is 
that the bank accepts credit card payments, by means of which users can feed 
their ecash accounts. 

We concentrate on the basic operations that manipulate ecash coins. Other 
important ingredients of electronic commerce protocols, such as certificates and 
receipts, are omitted as these parts are more or less independent of the way the 
core protocols are implemented. 
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Withdrawal By means of the withdrawal protocol, users are able to convert 
money from their ecash accounts into ecash coins. Access to the ecash account 
is only possible if the user is able to sign the withdrawal request, where the 
signature is checked against the public key registered with the ecash account 0 
The coins obtained in a withdrawal are stored on the user’s hard disk. By default 
the coins are stored in a password-encrypted manner to prevent them from being 
stolen (copied). 



Payment To pay a certain amount, a set of coins is selected such that the values 
add up to the required amount. In the on-line ecash system, this set of coins is 
then encrypted for the bank, using the bank’s public key, to prevent that the 
shop or anybody else can steal (copy) the coins. The shop deposits the payment 
at the bank, who credits the shop’s ecash account if all coins are valid and none 
of the coins has been spent before. Accepted coins are added to the database of 
spent coins so that double-spending will be detected. 



Payment Deposit In the on-line ecash system this protocol is part of the pay- 
ment protocol as executed by the shop. In an off-line ecash system this protocol 
is executed at a later moment, preferably in batch mode. An important prop- 
erty of the payment protocol is that the payment deposit is made specific to the 
payee. That is, a payment deposit for a specific payee cannot be deposited to 
any other account than the account of the specified payee. 



Coin Redemption It is possible to return coins directly to the mint without 
using them in a payment. A natural restriction is that the number of coins 
that a user redeems is not allowed to exceed the number of coins that has been 
withdrawn by the user; a more refined way is to monitor this per coinage and 
per denomination. This protocol is used when expired coins are refreshed, or to 
improve the distribution of the coin denominations. 



Recovery If desired, users are able to resurrect coins that have been lost, for 
instance, because of a hard disk crash. By means of a special recovery protocol 
executed between the user and the mint, all the coins that have been withdrawn 
by the user since the previous checkpoint can be reconstructed. However, only 
coins that have not been spent before will be usable for new transactions. (The 
same effect can be achieved when users keep backups of their coins.) 

^ A simple way to set-up ecash clients is to assume that the software and the bank’s 
public key are presented to the user securely (e.g., on a sealed floppy disk). The user 
also gets an account number and a PIN code from the bank. At home the user installs 
the ecash client, generates its own private key/public key pair, and registers it with 
its ecash account by sending it to the bank together with the PIN code (everything 
encrypted with the bank’s public key). The user’s private key can be stored in a 
password-encrypted manner on the hard disk. 
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4 Preliminaries 

RSA Signatures For authentication of messages we currently use the RSA 
public key cryptosystem. Each participant picks its own RSA key pairs at ran- 
dom. The public key consists of a modulus n = pq of prescribed size, where p, q 
are two randomly generated primes of equal size, and an exponent e, which is 
co-prime with <j){n) = (p — 1)(<7 — !)• The private key d is the multiplicative in- 
verse of e modulo that is, the unique number d satisfying de = 1 mod 4>(ji), 
which we denote by 1/e. 

To sign a message m G 2* , where the signer has private key d and public key 
(e, n), the signer computes the signature s = mod n. To verify the signature 
we check that = m mod n; this identity must hold as we have the identity 
= m mod n, since = 1 mod n for all m S 2* . Actually, it can be 

proven that = m mod n for all m G 2„. 

For various reasons (e.g., because RSA signatures can be existentially forged 
as described above: select an arbitrary s and take m = mod n, then s is a valid 
RSA signature on the “message” m), the actual message is usually first trans- 
formed into a related message by applying a one-way hash and/or redundancy- 
adding function / to it and then signing the result f(rn). In the next section we 
will see an example of such a function /. 



Hybrid Encryption The RSA cryptosystem can be used for encryption as 
well. To encrypt a message m, 0 < m < n, for a receiver with public key (e,n), 
the sender computes the ciphertext c = mod n and sends c to the receiver. 
To decrypt the message, the receiver uses its private key d to compute c‘^ mod n, 
which is equal to mod n = m. 

In practice, the use of public key encryption is often limited to the encryption 
of session keys. A symmetric encryption algorithm is then used to encrypt the 
actual message with the session key. In the ecash system, we also use such a 
hybrid encryption method (or, “envelope method” as it is sometimes called), 
where we combine RSA with 3-DES (with 112 bit keys). For reasons of efficiency, 
it is often advantageous to use public exponent e = 3; encryption of the session 
key then amounts to two modular multiplications, and poses no security risk as 
long as some well-known attacks are taken into account. 

5 Ecash Coins 

We will now have a closer look at the internal structure of ecash coins. For each 
coinage (short for a “generation of coins”), the mint will randomly generate a 
fresh RSA modulus N = pq, keeping the primes p, q secret by storing them in a 
safe place. Preferably the mint’s private keys are only used within the boundaries 
of tamper-resistant devices, while backups are kept between several entities using 
secret-sharing techniques. In this way, it is prevented as much as possible that 
private keys are compromised through attacks by insiders. 
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3 5 


7 


11 


13 


17 


19 


23 


29 


31 


37 


41 


Dy 


$0.005|$0.01 


$0.02 


$0.04 


$0.08 


$0.16 


$0.32 


$0.64 


$1.28 


$2.56 


$5.12 


$10.24 



Table 1. A binary scheme with k = 12 different denominations 



The denominations of a coinage are encoded by using different public expo- 
nents (but the same modulus). Let k denote the number of different denomina- 
tions, and let denote the first k odd primes. In order that each Vi is a 

valid RSA exponent, we have the condition that each vi is co-prime with </)(A^), 
that is, gcd(ui, 4>{N)) = 1 for i = 1, . . . , We denote the denomination that is 
associated with public exponent Vi by Dy.] see Table Q for an example. 

To limit the storage space required for ecash coins we take full advantage 
of the message recovery facility of RSA signatures. This is particularly useful 
because ecash coins are in fact RSA signatures on small messages. Thus we get 
the following form, where an ecash coin C of denomination consists of an 
RSA signature only: 

C = mod N. (1) 

For concreteness assume that x is 160 bits long, and let Ti denote a one-way 
hash function whose output length is 160 bits as well (like SHA-1). Function / 
is a redundancy-adding function defined by 



f{x) = xt\\---\\xx II Xo, 

with Xo = X and Xi+i = 7i(xo || •• • || Xi). Parameter t is fixed such that the 
total length of f{x) is about equal to the size of the modulus N. (Actually, the 
bit string f{x) is truncated such that the corresponding integer is always less 
than N.) Note that function / may alternatively be defined by f{x) = yt, with 
yo = x and y^+l = U{yi) || yi. 

In current ecash implementations RSA moduli used for ecash coins are at 
least 768 bits long; for this size forgery of ecash coins is considered entirely 
infeasible — certainly within the limited time- frame that a coinage is valid. Hence, 
a storage of about 100 bytes per coin on the user’s side is required. With today’s 
hard drives and memory chips there is absolutely no problem of storing any 
sensible number of coins. Over time this will only improve as the required key 
length for RSA is expected not to double every year or so, while the storage 
capacity of modern devices does. 

As for the coin storage on the mint side, we have the important observation 
that after checking the validity of a coin signature, and checking that the coin 
has not been spent before, it suffices to store the coin number only. As described 

^ This condition may be tested efficiently by precomputing 14 = nf=i '*^0 verifying 
whether gcd(Vfc,p — 1) = 1 and gcd(Vfc, g — 1) = 1. Note that this condition on the 
primes p, q can easily be met by choosing them from the set of safe primes (p = 2p'-|-l, 
q — 2q -I- 1 with p' , q prime), but we do not want to limit the set of candidate primes 
more than necessary. 
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above, we have fixed the size of the coin number at 20 bytes. The only condition 
on the size of the coin numbers is that it is large enough to prevent that the 
same coin number is accidently generated for coins of the same coinage. (As 
a slight refinement, note that it suffices that the coin numbers are unique per 
denomination.) By the standard result of the birthday paradox, the probability 
that two coins will be equal when the coin numbers are picked uniformly at 
random from {0, is bounded by , as long as at most B coins 

of the same type are generated. This shows that the probability that two coin 
numbers collide is truly negligible for any practical number of coins B. Since the 
number of coins per coinage is limited anyway (see Section , this analysis in 
fact shows that the size of the coin numbers can also be limited to 64-80 bits 
(8-10 bytes), say, if desired. Hence, a 1Gbyte hard disk can already store more 
than 100 million coin numbers. 



6 Protocols 

We consider the withdrawal protocol, the payment protocol (including the pay- 
ment deposit), and the recovery protocol. Each protocol is described at a level of 
detail that permits us to explain the main security features of the ecash system. 

6.1 Withdrawal 

For each ecash coin to be withdrawn from a user’s bank account, the user and 
the mint execute an instance of Chaum’s blind signature protocol j( Ta,83| . This 
protocol is executed in parallel as many times as required to withdraw the desired 
amount. The distribution of the coin denominations is chosen in such a way that 
it is guaranteed that — no matter how the money is spent — at least a certain 
number of payments can be made. The protocol for one coin is depicted in 
Figure ^ Apart from the random coin number x, the user also picks a random 
number r G which is used to blind the “message” f{x) to be signed by 
the mint. Since r G Z)(r its inverse 1/r exists, hence the blinding factor can be 
removed again to obtain the coin C = /(a;)^/" mod N. 

Regarding the security of this part of the ecash system, the important ques- 
tion that needs to be answered is whether it is infeasible to obtain more or 
other coins than prescribed by the withdrawal protocol of Figure E The answer 
is that an in-depth security analysis shows that (in a reasonable model) any 
way to obtain more or other coins than prescribed by the withdrawal protocol 
is equivalent to breaking the RSA assumption (which roughly states that it is 
infeasible to compute for randomly selected y G 2*). For the scope of this 
paper, we will confine ourselves to two aspects of this analysis that are specific 
to the ecash system. 

First, there is the fact that we use not just one, but a number of public 
exponents with the same RSA modulus to encode the different denominations 
within a coinage. This raises the question whether, for instance, coins of lower 
denominations cannot be combined into coins of higher denominations. More 
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User Mint 

[N = pq] 

X €r {0, 1}^®° (coin number) 
r Gr (blinding factor) 

M ^ f{x)r'" mod N 

M 

Debit account with 
S ^ mod N 
S 

C ^ S/r mod N 
C"' = fix) mod N 
Store coin C 



Fig. 1. Withdrawal of a coin C = mod N of denomination Dy 



formally, the question is whether for randomly selected M G 2^, it is feasible to 
compute, say, from the values {M, . . . , Recall that the 

vfs are pairwise co-prime. For a very different purpose, but equally applicable 
to our setting, Shamir has shown that this question is answered in the negative: 
he showed that given the values {M, . . . , the computation is 

just as difficult as if these values weren’t given at all. 

Secondly, there is the fact that the mint will just accept any message M, and 
return S = mod N to the user — but each time debiting the user’s account 

with Dy, even if the user picks the message M of the wrong form. So, there is no 
guarantee that the message M is of the prescribed form f{x)r'", where the user 
knows X, r, which contrasts with the usual setting for RSA signatures, where the 
signer will ensure that each message signed is of the required form /(m), say. In 
fact, by means of an example we will now show that it is possible to obtain valid 
coins although we deviate from the prescribed protocol. 

Consider the following approach. We are going to obtain two coins Ci = 
fixi)'"^ and C2 = f{x2)'’'^ of denominations v\ and V2 respectively. However, 
instead of just asking the mint to sign f{xi) and f{x2), respectively, we do it as 
follows. 

1. Ask the mint to sign Mi = f{xi)'"^fix2)'^'^ for denomination Dy^, which 

results in Si = . 

2. Subsequently, ask the mint to sign M2 = Si for denomination Dy^, which 

results in S2 = = f{xi)^^'^^f{x2)^^'^^- 

3. Finally, using the fact that gcd(ui,U2) = 1, hence there exist ti,t2 such that 
tiVi +t2V2 = 1, we extract the coins Ci and C2 from S2' 

fixiY^ f{x2)-^^ = = Cl, 

SY'"^ f{xi)-^^ f(x2Y^ = = C 2 . 
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So, although we do not follow the protocol as described in Figured we are able 
to obtain two valid coins anyway. (If desired, it is possible to blind the second 
request to the mint (step 2), such that the mint cannot detect the deviation.) 
The net result, however, is not very encouraging: we have obtained two coins 
for a total value of + Dy ^ , but also the account has been debited with this 
amount. 

Extending work by Shamir and work by Akl and Taylor ETHHI, 

Evertse and van Heyst showed that for a very general class of deviations from the 
prescribed protocol, nothing is to be gained EHniEHnni- As shown by Chaum 
ITTCTI . however, “deviations” as exemplified above can be used to improve the 
efficiency of the withdrawal protocol. For example, it is perfectly safe to collapse 
steps 1 and 2 in the above protocol, where the mint issues a signature w.r.t. 
exponent V\V 2 (charging, of course, Dy^ + Dy^ for this service). This cuts the 
communication costs with the mint by a factor of two, and also saves the mint 
from performing one signature. Needless to say, this method can be extended to 
collapse the withdrawal of any number of coins, as long as each denomination 
does not occur more than once. 

6.2 Payment 

Before a payment actually takes place, payer and payee have to come to an 
agreement about what the object is that is going to be puchased and for which 
amount X . We assume that the result of this negotiation is recorded in the string 
pay-spec. For later reference, the payer will also assign a random transaction 
number IDtrana to the payment (the use of successive transaction numbers might 
enable the bank to link successive payments made by the same user). 

Next, the payer will select a set of coins Ci, . . . , C/ from its coin supply, such 
that the total value of these coins equals the requested amount X. To pay a 
payee with identity ID shop, the payer then assembles a payment message that 
consists of the concatenation of pay- spec, IDtrana and an encrypted message 

Y for the bank: 

Y = EpKs^„,,iIDtrana |1 I D shop || H(pay-spec) II Tf(pay-code) || Ci || . . . || Ci), 

where E denotes a hybrid RSA encryption method (using 3-DES), as explained 
in Section 0 Upon receiving this message, the payee will then sign and forward 
a payment deposit message consisting of 7f(pay — spec), IDtrana and the en- 
crypted message Y to the bank. Finally, the bank decrypts Y and checks the 
values of IDtrana, IDshop, and 7f(pay — spec), and then proceeds to check the 
validity and freshness of the coins Ci, . . . , C/. Only if all coins are accepted, the 
payment is accepted as well, and the coins are stored for future double-spending 
checks. 

A few remarks regarding security. It is important that neither the payee 
nor any eavesdropper can extract the coins from the payment message. For this 
reason, the coins are encrypted with the bank’s public key. (Note that public 
key encryption is required in this case, because the bank and payer cannot use 
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a shared secret key, as the payer needs to remain anonymous.) Also, note that 
although the string pay-spec itself is never shown to the bank, the payee is sure 
that the payer used the same string, since the bank compares the hash values 
provided by the payer and payee, respectively. In this way the transaction details 
remain hidden from the bank; if required, however, either the payer or the payee 
can later reveal the string pay-spec which can then be checked against the data 
stored at the bank. 

Finally, let us briefly describe how interrupted payments can be resolved, in 
case the payer and payee aren’t able to recover from the interruption by normal 
means. Due to network problems, the payment protocol may be interrupted 
at several stages, but to the payer it only matters whether (i) the payment 
wasn’t processed by the bank, or in any case it was not credited to the payee’s 
account, or whether (ii) the payment was processed by the bank and credited to 
the payee’s account. To find out about the status of a payment, the payer can 
either redeem the coins C\, . . . ,Ci on an individual basis, or find out about the 
complete payment by sending message Y to the bank. 

In the latter case, the payer proves to be the owner of the payment by 
revealing the value of pay-code, to which the user committed by including 
Ti(pay-code) in the message Y. If the payment turns out to be credited to 
the payee’s account, the bank signs a statement to this effect, which the user 
can then show to the payee to prove that the payment arrived at the payee after 
all. 



7 Privacy 

We present the by now standard argument why the ecash system protects the 
privacy of its users. To fully protect the users’ privacy, the system must not only 
satisfy the requirement of untraceability, but also the stronger requirement of 
unlinkability; a system in which each user gets a pseudonym is not sufficient to 
protect the privacy of its users. 



Untraceability More precisely, this property is called payer-untraceability (or, 
payer-anonymity). This means that individual payment transactions are not 
traceable to the user who acted as the payer in such a transaction. The in- 
formation that the payee and its acquirer obtain from the transaction details 
does not contain any information as to which user took part as the payer. 



Unlinkability This property says that it should even be impossible to link any 
two payment transactions originating from the same user. 

To appreciate the difference between untraceability and unlinkability consider 
the following scenario. When you buy a prepaid telephone card you can do this 
completely anonymously at a newsstand (paying the card with cash) . Later when 
you use the card in a public phone the telephone company will have no clue that 
it is you making the phone call because you bought it anonymously. That is. 
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Fig. 2. Life-cycle of a coinage 



the individual telephone calls are untraceable, as they cannot be connected to 
your identity. Suppose however that the telephone company gives every card a 
unique number, which is quite realistic as this is a basic mechanism to detect 
fraud (i.e., to find cards on which the total spent is larger than the card’s value). 
Then it is easy to keep a file per card of all phone numbers called from that 
card (and possibly the time and date of the calls as well). Since a similar file is 
kept per home-phone as well, a simple pattern matching procedure will in many 
cases reveal the identity of a card’s owner. Thus, although the card is obtained 
anonymously, the identity of the card’s owner can be revealed anyway because 
all calls from the same card are linkable. 

We now argue why the ecash withdrawal protocol protects the users’ privacy 
in an information-theoretic sense. As untraceability is weaker than unlinkability 
we only have to show that the ecash coins are unlinkable. Consider a fixed 
denomination Let Sa denote a signature of denomination Dy that has been 

issued to some user A, and let Cb denote a coin of denomination Dy that has 
been spent by some user B (A and B are not necessarily different). For any 
such pair (Sa,Cb) there exists a unique blinding factor tab G that satisfies 
Cb = Sa/tab mod N. In other words, each signature issued by the mint matches 
equally likely with any of the coins spent. So, in an information-theoretic sense, 
there is no way the bank will be able to link coins that belong to the same user. 

8 Coinages 

Key Schedule In practice, an ecash mint will work with several coinages at 
the same time. For each coinage the mint generates a fresh RSA modulus, as 
described in Section 0 Hence, there is a one-to-one correspondence between 
the RSA moduli and the coinages. Apart from the RSA modulus, a coinage 
has at least the following attributes: the identity of the mint, the sequence of 
denominations, the currency, and a key schedule (i.e., expiration dates) as in 
Figure |21 These attributes are distributed with each coinage. Note that the 
private key can in fact be removed as soon as withdrawals are deactivated, while 
the public key must be available until the coinage becomes invalid. 

There are two main reasons why coinages are refreshed on a regular basis, 
say every three months. First, there is the standard reason for refreshing keys, 
namely to limit the risk that the secret key is compromised. There are two direct 
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ways this may happen. In the first method, the attacker will try to find the secret 
key from the public key only, possibly using the mint as a signing oracle. In the 
second method, the attacker simply tries to get hold of the secret key by breaking 
into the bank or into its computer network, possibly assisted by insiders. 

The other important reason is to limit the size of the “spent coin” databases. 
Using a scheme like that of Figure El spent coins are first stored on hard disk 
to enable fast checking for duplicates. After some time the coins are moved to 
tape, and during that period it will still be possible to check for duplicates, but 
using a slower procedure (which is only available so that users can return coins 
when they haven’t used their ecash for a longer period of time). Eventually, a 
coinage will become invalid and the tapes can be removed. 



Clustering Apart from a division in time, where coinages are refreshed every 
three months say, we can also use a division in space. That is, instead of viewing 
all users as one big set of users, it makes sense to divide the users in clusters. 
Each cluster is chosen sufficiently large such that the behaviour of the individual 
users is not visible. The advantage is that by limiting the size of a cluster that 
the corresponding parts of the “spent coin” database are independent of each 
other. This enhances the scalability of the system considerably. The way the 
bank divides its users into clusters should be publicly verifiable, and not at 
the discretion of the bank (to prevent the bank from introducing a few small 
clusters). There are many ways to accomplish such a fair division into clusters. A 
simple idea is to first take a cryptographic hash of the user’s identities, and then 
define 2* clusters, t > 0, by looking at the first t bits of the hash value. Assuming 
that the bank cannot influence (the representation of) the user’s identities, the 
users are thus evenly spread over the clusters. 

If so desired, other types of clusters like age-groups can also be encoded as 
different coinages. Certain shops could then be made to accept ecash from certain 
age-groups only. This is an example of the token functionality that can also be 
achieved with the same core protocols of ecash. The token functionality is in 
turn subsumed in the general notion of electronic credentials, which encompasses 
things as diverse as theatre tickets, driver’s licenses, passports, diplomas, etcetera 
(e.g., see [KJha92j 'l. 

9 Off-line Ecash 

It is interesting to consider the development of privacy-protecting off-line cash 
protocols. Since the introduction of Chaum’s double-spending paradigm for such 
protocols and the first solutions for the problem ten years ago |UFN90| . the 
protocols have developed into an efficient and relatively simple system for off- 
line cash. Chaum’s double-spending paradigm says that the privacy of a user is 
completely protected as long as the user spends each coin not more than once. 
However, if a user is able to manipulate its payment device such that some coins 
are used more than once, the protocols are such that the identity of the double 
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spender can be computed. In other words, the protocols satisfy the property 
“once concealed, twice revealed” (courtesy Franklin and Yung EM). 

fFY^, eliminates withdrawal protocol, |T3ra,94al lRra94hj introduces, 

and jSch95j 

Recently, several extensions to the basic protocols have been proposed, such 
as an efficient method of making the privacy revokable by a trusted third party. 
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Abstract. This paper discusses the standards and activities of the ISO/IEC 
committee SC 27 "Information technology - Security techniques", which 
develops general security mechanisms, guidelines and criteria for IT security, 
and of the European Telecommunications Standards Institute, which specifies 
security services as part of the standardisation of telecommunication systems. 



1 Introduction 

Until well into the seventies, research in the field of cryptography, and 
consequently the use of cryptographic techniques for information security, was 
largely restricted to government institutes. The increasing influence of information 
technology, its spread to everyday life and its need for security products inevitably 
resulted in a surge of activity in this field that affected both the IT industry and 
academic institutions. The need for protecting (open) systems also produced a 
response from international standardisation bodies. A prominent role was played by 
the Consultative Committee on International Telegraphy and Telephony (CCITT) 
which published its Recommendation X.509, The Directory - Authentication 
Framework in 1988. 

The first International Standards were published in the mid-eighties by the 
Technical Committee TC 68 "Banking, securities and other financial services" of the 
International Organization for Standardization (ISO). They were based on the Data 
Encryption Standard (DES) and its modes of operation [10,11] of the US National 
Bureau of Standards (NBS) for the protection of unclassified government 
information. These standards had also been adopted by the American National 
Standards Institute (ANSI) as American national standards. 

This period also saw the establishment of an international group to work 
exclusively on the standardisation of cryptographic techniques. The first meeting of 
Working Party 1 (WPl) on data encryption of the ISO Technical Committee TC 97 
"Information processing" took place in lanuary 1981. In 1984 WPl was transformed 
into the subcommittee SC 20 "Data cryptographic techniques". The scope was the 
standardisation of cryptographic techniques for use within information processing 
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systems. SC 20 had three WGs dealing with "Secret key algorithms and applications" 
(WG 1), "Public key crypto-systems and modes of use" (WG 2) and "Use of 
encipherment techniques in communication architectures" (WG 3). The programme 
of work included the standardisation of encryption algorithms such as the DBS. In 
1986, after several years of preparatory work, ISO 8227 "DEAl (Data Encryption 
Algorithm 1)" was ready for publication. In early 1986 the USA had however 
proposed to TC 97 to change the scope of SC 20 so that it would not develop 
standards for encryption algorithms. TC 97 recognised at its Plenary meeting in May 
1986 that the standardisation of encryption algorithms was a politically sensitive area 
of activity in several member countries and referred the issue to the ISO council. The 
council decided not to publish ISO 8227. Furthermore, all other work on the 
standardisation of cryptographic algorithms had to be discontinued shortly afterwards. 
Due to this change in its programme of work and the complexity of its topics SC 20 
only completed two standards until it was dissolved in 1989. For more information on 
the early days of the security standardisation within TC 97 see [20]. 

The discussion on the need to standardise cryptographic algorithms did however 
continue. While TC 68 still standardises such algorithms for use in banking, the scope 
of SC 27, the committee which succeeded SC 20, explicitly excludes their 
standardisation for Information Technology. A new initiative was taken at the 
October 1996 plenary meeting of SC 27 where consensus was reached to ask the 
parent body JTC 1 to lift this restriction. The JTC 1 plenary meeting in December 
1996 unanimously agreed to have the revised scope of SC 27 balloted by its national 
member bodies. 

Cryptographic algorithms constitute only one component of the security package 
required for the (cryptographic) protection of information systems. Message 
authentication to detect manipulations, authentication of network nodes, computers 
and users to prevent unauthorised access, management of the (secret) keys used for 
the algorithms, criteria for the evaluation of systems and management guidelines are 
only a few examples of standardisation projects in the field of IT security carried out 
by standardisation bodies and industry organisations throughout the world. 



2 International Standardisation 

Besides the International Organization for Standardization (ISO) there are two 
organisations which are involved in standardisation issues on a global level. These are 
the International Electrotechnical Commission (lEC) and the International 
Telecommunication Union (ITU), the Telecommunication Standardization Sector 
(ITU-TS) of which took over the work of the CCITT. Apart from these organisations 
there are regional bodies such as CEN, CENELEC and ETSI in Europe and industry 
interest groups such as IEEE, the Institute of Electrical and Electronic Engineers, and 
ECMA, the European Computer Manufacturer's Association, which are heavily 
involved in the standardisation of security techniques. Such groups have, due to their 




International Standardisation of IT Security 



355 



close link with applications and their implementations, the necessary resources in 
manpower and time. They can create (regional) de-facto standards which may in the 
medium term compete with the International Standards from ISO, lEC and ITU. 
Those are usually not application specific, more on a generic level and take, due to 
the multitude of interests of the supporting organisations, companies, and delegates as 
well as quite often a lack of resources, much longer to complete. 

In the remaining part of this chapter we will restrict the discussion to the work of 
ISO and lEC. Eor information on the general terms and their definitions concerning 
standardisation and related activities of ISO and lEC see the ISO/IEC Guide 2 [14] 
which is published in the three official languages English, Erench and Russian. 



2.1 JTC 1 

In 1987 ISO and lEC founded the Joint Technical Committee 1 (JTC 1) 
"Information technology" to harmonise their standardisation efforts in this field. JTC 
1 took over the work of TC 97 and, in particular, the standardisation of security 
techniques. The "Banking Committee" TC 68 continued to develop, as an 
independent ISO committee, its own security standards. JTC 1 has currently 20 
subcommittees covering the various aspects of the standardisation of Information 
Technology. These range from "Vocabulary" (SC 1), which plays an important part in 
ensuring the compatibility of standards, via "Programming languages, their 
environments and systems software interfaces" (SC 22) to "Open-edi" (SC 30), which 
is producing generic IT standards for open electronic data interchange, and to 
"Automatic data capture", on which the newest committee, SC 31, is working. It 
should be noted that the number of a subcommittee which has been dissolved is not 
re-used. Eor up-to-date information not only on JTC 1 but on all ISO committees the 
reader is referred to the "ISO Bulletin" [12] which is published monthly and contains 
the meeting calendars of the TCs and SCs, a listing of all documents having been sent 
for ballot and standards having been published, confirmed or withdrawn. 

Standards for products and aspects of IT security are developed in particular by 
SC 17 "Identification cards and related devices", SC 21 "Open systems 
interconnection, data management and open distributed processing" and SC 27 
"Information technology - Security techniques". Whereas the security related 
activities of SC 17 concentrate mainly on smart cards, i.e. integrated circuit cards 
with microcomputers, SC 21 develops general security frameworks (e.g. for 
authentication) as part of its scope covering the various aspects of OSI. The work of 
SC 27, which a "pure" security committee, will be discussed in detail later. 

Members of JTC 1 and its subcommittees are national standards institutes, 
whereby each country may be represented by one institute only. As of March 1996, 
29 countries participate in the work of JTC 1 as so-called P(articipating)-members 
with the right to vote, while 27 countries have the status of an Observing Member 
(0-member). It should be noted that a P-member of an SC is not necessarily a P- 




356 



Klaus Vedder 



member of JTC 1 and vice versa. Voting takes place on a "one body, one vote" basis. 
Details on the structure of JTC 1 and its operational procedures can be found in the 
"Directives" [15]. 



2.2 The Security Committee 

SC 27 which was established by JTC 1 in 1989 as the successor to SC 20 had its 
first Plenary meeting in Stockholm in April 1990. SC 27 took over most of the work 
items of SC 20 with the exception of those of SC 20AVG 3 which were assigned to 
SC 6 "Telecommunications and information exchange between systems" and the 
already mentioned committee SC 21. The scope of SC 27 is the standardisation of 
generic methods and processes for IT security. Important aspects of the work beyond 
the purely cryptographic part of IT security include terminology, guidelines for IT 
security management and criteria for the evaluation of IT security. Explicitly 
excluded are the standardisation of cryptographic algorithms and the incorporation of 
the security mechanisms into applications. A synopsis of each project of SC 27 is 
contained in the "Standing Document" SD7: Catalogue of SC 27 Work Items and 
Standards. A listing of the current documents of the projects, the names of the Project 
Editors and the target dates is contained in SD4, the SC 27 Programme of Work. Both 
documents are updated after every meeting of the three Working Groups of SC 27 
and are available on the Web [17,18]. 

The day-to-day work of the subcommittee is handled by the Secretariat, which is 
currently held hy DIN (the German institute for standardisation), and the SC 27 
Chairman. He chairs the annual Plenary meeting of SC 27 and is supported in this by 
the Secretariat. The Plenary is responsible for the technical and administrative 
"guidance" of the WGs. It appoints the Conveners (i.e., the chairpersons of the 
Working Groups), approves at a WG's suggestion the promotion of a project to the 
next higher level (see helow), is responsible for setting up new projects, has to 
endorse the appointment of Project Editors and Liaison Officers proposed by a WG 
(or relieves them of their duties) and deals with general questions relating to its field 
of work. As of October 1996 SC 27 had 21 P-members and 1 1 0-members. 



2.3 The Working Groups of SC 27 

As in most of the subcommittees the detailed technical work on the projects is 
done in Working Groups (WGs). The three WGs of SC 27 meet twice a year. The 
meetings are held at the same time in the same location to stimulate the exchange of 
ideas, to improve the flow of information and to achieve the necessary alignment of 
the projects assigned to the groups. 
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2.3.1 SC 27AVG 1: Requirements, Security Services, and Guidelines 

The work of WG 1 comprises, as its title suggests, the following activities: 

• Identification of application and system requirement components. 

• Development of models for services the mechanisms of which are specified 
by WG 2. 

• Development of supporting interpretative documents such as security and 
management guidelines, glossaries and risk analyses. 

The first standard completed by WG 1 was the Register of Cryptographic 
Algorithms (ISO/IEC 9979: 1991). This register had been developed to help users to 
overcome the problems inflicted by the decision that there was no standardisation of 
cryptographic algorithms by SC 27 as stated in its Scope and Area of Work. The 
information on an algorithm contained in the register depends on its provider. A 
listing of the algorithms registered is contained in SD7 [18]. Other standards 
developed by WG 1 include the general part for the multi-part standards on entity 
authentication (ISO/IEC 9798: 1991) and key management (ISO/IEC 1 1770: 1997). 

Due to the nature of the topics most other projects within WG 1 will be published 
as so-called Technical Reports. Of particular interest are the "Guidelines for the 
Management of IT Security (GMITS)" and the "Trusted Third Party Services". The 
first part of the five part report on GMITS discusses concepts and models for IT 
Security and is due to be published as ISO/IEC TR 13335-1. Parts 2 and 3 which deal 
with the management and planning and the techniques for the management of IT 
security, respectively, are in an advanced state. Work on the baseline approach and 
aspects on the application of services and mechanisms has only just started. Eor more 
information on these and the other projects of WG 1 the reader is referred to [18]. 
Also quite recent is the work on Trusted Third Party Services which are needed for 
the introduction of public-key cryptography on a large scale in an open environment 
and for non-repudiation services as well as the "consequential" arbitration required 
for such systems. 

WG 1 is also the main liaison body of SC 27 to the outside world both within and 
outside of JTC 1 and the realms of ISO and lEC. This and the fact that standards are 
(supposed to be) made for users are reflected in WG I's Terms of Reference: "WG 1 
recognises that it is user oriented and must satisfy the needs of a diverse community. 
This community ranges from security technicians to standards developers, all with 
varying concerns and needs (e.g., regulatory, financial, business, technical). The areas 
of need are also taken to include the systems and/or applications of the open systems 
environment. SC 27/WG 1 must maintain an awareness of other security-related 
activities outside of JTC 1". 

2.3.2 SC 27/WG 2: Security Techniques and Mechanisms 

WG 2 has essentially taken over the work of the two WGs of SC 20 dealing with 
secret key algorithms and public key crypto-systems. The merging of these fields of 
cryptography proved advantageous for the standardisation process. Work and status 
of WG 2 can probably best be summarised by quoting from its Terms of Reference: 
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"WG 2 provides a centre of expertise for the standardisation of IT Security techniques 
and mechanisms within JTC 1." 

One of the first (international) standards for a digital signature concept was 
published in 1991 as ISO/IEC 9797 Digital signature scheme giving message 
recovery. Due to the nature of the algorithm, which could - as often is the case in such 
a scheme - also be used for enciphering data by reversing the roles of the entities 
involved, the actual process is described in an informative annex. This standard was 
used in the drafting of Part 1 of the Digital Signature Standard (DSS) (ANSI X9.31). 
To cover the case of messages which need to be compressed prior to being signed, SC 
27 is developing a second part of ISO/IEC 9796 under the title "Mechanisms using a 
hash-function" as well as parts dealing with check-functions and the discrete 
logarithm. An overview on standards for the authentication of entities and messages is 
contained in [6] . 

The work of WG 2 covers the whole range of cryptographic topics on security 
mechanisms. Scope and Terms of Reference state that the "Areas of work include, for 
example, mechanisms relating to authentication, access control, confidentiality, key 
management, non-repudiation and data integrity. Techniques may be cryptographic or 
non-cryptographic". Though the scope explicitly mentions non-cryptographic 
techniques there are currently no such projects discussed within WG 2 due to lack of 
contributions and experts in this field. 

The following is a list of topics contained in the Programme of Work of WG 2. It 
should be noted that the projects usually deal with both symmetric and asymmetric 
techniques though these may be in a different state of completion. Some projects also 
include a part dealing with zero-knowledge techniques. For details on the projects and 
the degree of completion the reader is referred to [17,18]. 

• Modes of operation (2 International Standards); 

• Entity authentication (5 parts, four have been published as an IS); 

• Data integrity mechanism (message authentication codes) (1 IS); 

• Non repudiation (3 parts); 

• Digital signature schemes (2 parts, one has been published as an IS); 

• Digital signature with appendix (3 parts); 

• Hash - functions (4 parts, two have been published as an IS); 

• Key management (3 parts, one has been published as an IS). 

2.3.3 SC 27/WG 3: Security Evaluation Criteria 

When forming SC 27 it was recognised that the scope of the former SC 20 was too 
limited as it only covered techniques (apart from the projects of WG 3 on 
communication architectures) but not issues such as management guidelines and 
criteria for the evaluation of IT security. WG 3 was set up to develop a three-part 
standard on the latter based on the "Provisional Harmonised Criteria" for France, 
Germany, the Netherlands and the UK (ITSEC [2]). Details on this topic can be found 
in the report of a CEN project team [3] which also contains a proposal for a European 
solution. This paper has, however, been shelved due to the activities of Germany, 
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France, Canada, the USA and the UK, which have set up a working group, the 
Common Criteria Editorial Board (CCEB), to harmonise the "Provisional Harmonised 
Criteria" (ITSEC) with those of the USA and Canada and to develop the "Common 
Criteria". It was recognised that the work of the CCEB had of course some influence 
on the progress and work of WG 3 and a formal liaison was established between the 
two groups in October 1993. This proved beneficial to both parties as, in particular, 
several delegates and Project Editors of WG 3 were also members of the CCEB which 
ensured the flow of information. In April 1996 it was decided to replace the Working 
Drafts developed by WG 3 by the respective documents of the CCEB. They were then 
circulated as a CD. 

The Terms of Reference of WG 3 also include administrative procedures for 
evaluation, certification, and accreditation schemes as well as assessment and testing 
methods. A new work item on the registration procedures for protection profiles has 
been agreed within JTC 1 and a study period on testing and assessment methods was 
initiated by SC 27 at its Plenary meeting in Seoul in November 1995. 



3 Standards 

Standardisation bodies produce standards. What is a standard and what are the 
rules governing the development, the voting process and the maintenance of a 
standard? There is no standard definition of what comprises a standard as the interests 
of the various committees are too diverse. 

The ISO Memento [13] which is published annually in English and Erench by the 
ISO Central Secretariat provides the following information on ISO; "ISO (the 
International Organization for Standardization) is a worldwide federation of national 
standards bodies, at present comprising 118 members, one in each country. The 
object of ISO is to promote the development of standardization and related activities 
in the world with a view to facilitating international exchange of goods and services, 
and to developing cooperation in the spheres of intellectual, scientific, technological 
and economic activity. The results of ISO technical work are published as 
International Standards.” 

How does one get from a first idea to an International Standard? As a rule, an 
International Standard and a Technical Report will pass through the following stages 
in the course of its life. 

Study Period: This period allows a committee to (informally) study a subject 
which is considered to require standardisation. The outcome of a study period should 
be a documentation showing that the topic should either be dropped or subjected to an 
NP ballot. 
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New work item Proposal (NP): A proposal put forward by the JTC 1 Secretariat to 
the national member bodies of JTC 1 (in response to an application from an SC or a 
national body) that a subject should be adopted by an SC as a new work item. 

Working Draft (WD): Internal document of the WG or SC dealing with the project. 

Committee Draft (CD), Preliminary Draft Technical Report (PDTR): If a WD is 
considered sufficiently stable, it is registered by the SC as a CD (formerly: Draft 
Proposal) with the Information Technology Task Force (ITTF) of ISO/IEC in 
Geneva. It is then circulated for a three months letter ballot by the SC to the national 
member bodies of the SC for their comments. In the case of a PDTR the document is 
distributed by JTC 1 . 

Draft International Standard (DIS), Draft Technical Report (DTR): If a CD has 
received the necessary support, and no more technical modifications are to be 
expected, the SC requests the ITTF to ballot the document as a DIS. The ballot is at 
JTC 1 level and lasts for four months. If the DIS receives the necessary support (see 
[15]) then there is, generally speaking, no further obstacle to it being published as an 
International Standard. DTRs are as PDTRs distributed by JTC 1 . 

International Standard (IS), Technical Report (TR): Following publication as an 
International Standard or Technical Report, any technical errors discovered can be 
pointed out by means of a "Defect Report". On the basis of this report, submitted by a 
national member body, the SC decides whether the standard is to be revised or, 
possibly, withdrawn. 

Review: Every standard/report is reviewed hy JTC 1 at five-year intervals. At this 
point it may be confirmed for another five years, withdrawn or revised. Prior to the 
formal decision by JTC 1 the SC responsible for the project analysis the standard and 
issues a recommendation to JTC 1 . 

Looking at the times needed to process a document at the various stages, whereby 
circulation for comments at WD level and letter ballots at CD level are usually carried 
out more than once, and bearing in mind that the WGs meet only twice a year, it 
becomes clear that the anticipated time of three years from conception to publication 
of a standard is achievable only under optimum circumstances. It is in fact the 
exception rather than the rule. In the field of Information Technology, such lengthy 
gestation periods do not always keep up with the demands of the market. To speed up 
the work JTC 1 has established some new procedures such as the shortening of the 
DIS letter ballot from six to four months, the "Fast Track Procedure" by means of 
which an existing national standard can go straight to DIS level and the possibility to 
have "parallel" voting on a new project as both an NP and a CD. Details on the phases 
in the life of a standard and the rules for its development are given in [15,16]. 
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4 European Standardisation 

In an age of globally operating companies and a (more or less) open international 
marketplace, the existence of regional standardisation bodies at first seems 
anachronistic, and not necessarily conducive to general technical and economic 
progress. However, standards also reflect common interests, which can be translated 
much more quickly into standards on a regional level and, as a result, into market 
share on a wider level. The importance of European standards was underlined by the 
EC Commission in its Green Book of October 1990 on the development of European 
standardisation [19]. 



4.1 The European Bodies 

The bodies corresponding at European level to the three international 
standardisation organisations ISO, lEC and ITU are the "Comite Europeen de 
Normalisation" (CEN), the "Comite Europeen de Normalisation Electrotechnique 
(CENELEC) and the "European Telecommunications Standards Institute" (ETSI). 
The Bulletin of the European Standards Organizations [5], a monthly report published 
jointly by the three institutes, contains a list of adopted and draft standards, as well as 
information on important decisions and mandates of the three organisations. 
Information on the European standardisation requirements for information systems 
security can be found in a joint document of the three bodies [4]. The impact of the 
Commission's Green Book about the security of information systems [1] on the work 
of CEN and CENELEC remains to be seen. 

To prevent duplication of effort, agreements between the three European bodies 
CEN, CENELEC and ETSI on one side and ISO, lEC and JTC 1 on the other side 
have been or are about to be signed. Both the "Vienna Agreement" between ISO and 
CEN as well as the "Lugano Agreement" between CENELEC and lEC were signed in 
1991. The agreement between ETSI and JTC 1 has been concluded in November 
1996 and is subject only to ratification. 

Membership of CEN and CENELEC is along the same lines as membership of ISO 
and lEC, i.e., through the national standards institutes of the EU and EETA countries. 
Each organisation has currently 18 members as well as affiliates from central and 
eastern Europe. Different is the use of a weighted voting system. While all members 
of ISO and lEC have formally the same rights, the weight of a member of the 
European organisations ranges from 1 to 10 depending on the size of the country. 



4.2 ETSI 

The European Telecommunications Standards Institute which is based in Sophia 
Antipolis, France, was established in 1988 with the aim of accelerating technical 
harmonisation in all areas of telecommunication in view of the development of a 
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common market. Membership is open to all companies and organisations with an 
interest in the creation of European telecommunications standards and the companies 
themselves nominate their delegates to the committees. The national standards bodies 
simply co-ordinate the voting. 

The standards developed by ETSI are dedicated to a specific application or 
technology and quite often form at the same time the basis for implementation by 
industry. The definition of an ETSI standard thus differs substantially from those 
quoted above: "A standard is a document that contains technical specifications laying 
down the characteristics required of a product, such as levels of quality, performance, 
safety or dimensions. It includes the requirements applicable to the product, as 
regards terminology, symbols, testing and test methods, packaging, marking or 
labelling." 

The standards which have been developed for GSM, the Global System for Mobile 
communications, and DECT, the Digital Enhanced Cordless Telecommunications 
system, include security models and risk analysis as well as the parameters and 
routines necessary for the implementation of the security functions. The European 
Telecommunications Standard ETS 300 175-7 [7] contains a risk analysis of DECT as 
well as authentication mechanisms and key management procedures. 

The specification of GSM as a digital, cellular mobile telecommunications network 
and its security functions started in 1983 within CEPT and is now handled by ETSI. 
Security functions in this context are, in particular, the cryptographic authentication 
of the user (using a chip card with non-volatile memory and microprocessor), the use 
of temporary identities to prevent a users' whereabouts being traced, and the 
enciphering of user data and user-related signalling information on the air interface. 
The cryptographic algorithms used for these purposes are handled on a need-to-know 
basis. To achieve interoperability and the possibility to roam across boarders and 
networks without any loss of security, the functions and features as well as the 
parameters had to be standardised [8,9]. The Technical Committee responsible for 
GSM has now established its own SubTechnical Committee to look after the security 
aspects of GSM and UMTS, the future Universal Mobile Telecommunications 
Systems. For an overview of the security functions and aspects of GSM the reader is 
referred to [21]. 

ETSI has also established two groups which solely deal with security aspects. The 
Security Techniques Advisory Group (STAG) was founded in 1992 to co-ordinate the 
security activities of the various committees and to advise them on security matters. It 
is also responsible for guidelines on the introduction of security services and for 
drafting design specifications for algorithms. The development of these algorithms 
and the protocols is the responsibility of the Security Algorithm Group of Experts 
(SAGE). 
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5 Outlook 

Standardisation in the field of IT security is currently at a decisive stage. The work 
of SC 27 is gaining momentum which is manifested in an increasing number of 
important standards having been published or close to being completed. They are, 
however, competing with an even more increasing number of national and industry 
standards as well as other International Standards not only in the "key-cryptography" 
area of WG 2 but also in the field of management and general concepts of IT 
Security. Whether SC 27 is going to be a key player will depend not only on the 
acceptance (marketing) of its work but also whether it can improve its time to market 
ability, its standards become more "applicable" by including cryptographic algorithms 
and thus form the basis from which to derive application specific standards. Two 
important steps have been taken with respect to the last two issues, the already 
mentioned initiative to standardise cryptographic algorithms and the discussions with 
TC 68 about a close co-operation. The latter was agreed upon at a joint meeting of the 
two committees in early October 1996 and was endorsed later that month by the SC 
27 Plenary. As a first step it is envisaged to set up a co-ordination group consisting of 
the SC 27 WG conveners and the TC 68 subcommittee chairmen to achieve a close 
liaison not only with respect to general matters of common interest and new projects 
but also to harmonise existing standards when they come up for review. 

There are several other aspects which influence the status and the success of SC 
27. The readiness to make funds available for "general" standardisation work has 
noticeably diminished. Furthermore, the sole existence of the various committees, a 
certain amount of sometimes unavoidable parallel development, or simply the lack of 
the basic standards, can result in International (or de-facto) Standards which, in spite 
of dealing with the same topics and having the same objectives, are not compatible 
with each other and lead to incompatible products. Efficiency and resources could 
doubtless be improved by better co-ordination between the committees through 
improved liaison (instead of working in parallel), the clearer definition of 
competencies, and, as contradictory as it may sound, shorter intervals between 
meetings. At least within ISO and lEC this should be achieved by having only one 
committee under whose roof all general as well as all application specific security 
standardisation should be united. Structures and procedures that have developed over 
many years are, however, very difficult to change. 

Glossary 

CCITT Comite Consultatif International Telegraphique et Telephonique 

CD Committee Draft 

CEN Comite Europeen de Normalisation 

CENELECComite Europeen de Normalisation Electrotechnique 

DIS Draft International Standard 

DTR Draft Technical Report 

ETSI European Telecommunications Standards Institute 
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FIPS 


Federal Information Processing Standard 
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International Electrotechnical Commission 
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International Standard 
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International Organization for Standardization 
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Abstract. This paper gives a view of the organisational infrastructure necessary 
for the successful implementation of information technology security. 
Guidance is given on the writing of security policies, the assessment of risks, 
the realistic appraisal of threats and the selection of countermeasures. All of 
the mechanisms available can then be put into their proper place within the 
organisation to achieve the desired security. Moreover, it will be possible to 
assess the cost-benefit of each element of the security programme in order to 
decide on the practical compromises to be made. 



1 Security 



1.1 What Is Security? 

In the context of information processing, security is usually defined as preserving 
the Confidentiality, Integrity and Availability of the information held in, processed in, 
or output from an organisation's computer systems. In the other papers in this 
collection there will be many different security mechanisms described, and the 
practical uses to which they can be put will be detailed. 

The purpose of this paper is to give a view of the conceptual infrastructure 
necessary to facilitate the implementation of security in whatever context is relevant. 
All of the mechanisms available can then be put into their proper place within the 
organisation to achieve the desired level of security. Moreover, it will he possible to 
assess the cost-benefit of each element of the security programme in order to decide 
on the practical compromises to be made. As an example of such practical 
considerations, a hank vault will keep valuables safe but the proud owner of a new 
bicycle does not install a bank vault in which to keep it. 



* The author wishes to acknowledge the help and advice given by R.J.Shute in the preparation of this 
paper 
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1.2 Where Does Security Management Start? 

Security management starts with the realisation that the word “management” is 
wrong in this context. The phrase which sums up the activity best is "Security 
Resource Focusing". This is because security cannot be imposed on any organisation 
made up of individuals; it can only be achieved by cooperative effort with all 
members of the organisation working together for a common end. 

Since the addition of security features to a system requires more work to be done 
(often including more actions by every user) it follows that performance and hence 
convenience deteriorates; the main thrust of Security Resource Focusing is to ensure 
that a reasonable compromise is made between the demands of the security measures 
and the benefits obtained. 

The decision to install security in the system must come from, or at least be 
endorsed by, and be championed by the highest levels in the organisation. There will 
be resistance from many users to the concept of extra work which does not benefit 
them directly, and only the highest levels can ensure that the best interests of the 
organisation as a whole take precedence over the local interests of the different parts 
of the organisation. The approach really must be one of educating the staff to “buy 
in” to the concept of security. 



1.2 Why a Security Policy? 

When an organisation has decided that it needs some security features in its 
system, the first action is for the top level of controlling management (the directors in 
a company) to nominate (or at least endorse advice on) what assets they feel need to 
be protected and what protection needs to be afforded to each such asset. This needs 
to be done in some considerable detail in writing. Such a document is known as a 
System Security Policy; it is part of a larger concept (often not a single document, 
and often partially unwritten) which is the general Organisation Security Policy. 

The need for such a written specification of the aims and objectives of the 
organisation in the security field is immediately apparent; this makes it the more 
surprising that there are many organisations in which such a document does not exist. 
If the technical staff implementing the policy do not know what they are supposed to 
achieve in meticulous detail then they will not achieve it. No organisation would 
dream of setting up a new office or factory without first preparing overall detailed 
plans. 



1.3 What Is in a Security Policy? 

A Security Policy is a written statement of what aspects of the organisation's 
information and processing facility are to be protected, and to what degree. It should 
not specify how these aspects are to be achieved. 
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1.4 Protected Assets 

For most organisations there are three sorts of information held and processed in 
their computer systems: private, normal and public. The physical assets (computers, 
discs, tapes, etc.) also need to be protected in order to protect the information held in 
them. 

1.4.1 Private Information 

Private information is the information which is most sensitive in terms of the 
organisation's operation, competitiveness or reputation. Examples might be: 

• plans for future products, which must not be revealed to competitors 

• take-over ambitions, which must not be revealed prematurely to the target 
company or to the stock market 

• differing suggestions for approaching anticipated problems, some of which it 
might be embarrassing to reveal because they will never be implemented 

• personal information about employees, suppliers or customers which is protected 
by law. 

1.4.2 Normal Information 

Normal information is the information which is not particularly sensitive in terms 
of the organisation's operation, competitiveness or reputation, but which should not 
be issued beyond the organisation without specific authority. Examples might be: 

• stock levels in each branch 

• movements of valuable stock and of key staff 

• internal memoranda regarding routine management activities 

• detailed technical specifications of existing products. 

1.4.3 Public Information 

Public Information is the information which is issued by the organisation to the 
outside world for dissemination to customers, to the general public, or in the press 
where such dissemination is considered to enhance (in some way) the organisation's 
operation, competitiveness or reputation. Examples might be: 

• announcements of future products, which (it is hoped) customers will buy 

• announcements of take-over bids, which legally must now be revealed to the 
target company and to the stock market 

• price lists. 

1.4.4 Physical Assets 

It is important to consider the more physical assets involved in information 
processing and storage will also need to be protected to a level comparable with that 
of the information contained in them. These include computers, discs, tapes, etc. 
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1.5 Protection Regimes 

Private Information in a paper system would have been kept in a locked filing 
cabinet, and would not have been made available to any but a select few members of 
the organisation. In a computer based system, such information will be kept under 
specific security protection to prevent unauthorised access; in transit across a 
network it will be encrypted at the highest affordable level that the relevant 
governments permit. 

Normal Information in a paper system, would be kept in the office (or only taken 
out by specific permission) and would not be left where casual visitors could read it. 
The protection to be afforded to such information, in a computer system, will 
probably be at the level that a normal multi-user operating system offers; in transit 
over the network some simple encryption (at most) will be all that is required. 

Public Information is very odd in that, while anyone may read it, only a very few 
members of an organisation are authorised to issue it. Documents such as press 
releases are often left in reception areas and waiting rooms where casual visitors can 
(and are encouraged to) read them, but their content is subject to the most stringent 
checks on its integrity before publication. Such information, in a computer system, 
will be kept in a specific set of files which can be read by anyone, but there will be 
strict controls on write access and some form of integrity check; similarly over a 
network, the integrity and authenticity of the data must be ensured but anyone can 
read the information, which may well be offered on a publicly accessible Internet web 
page. 

The protection of physical assets is also important in this context. The controls on 
the dissemination of information will be, in many cases, useless if the equipment 
containing the information (discs, tapes, or even entire computers) can be removed 
for analysis at the intruder's leisure on the intruder's own premises. Lest anyone get 
the wrong idea, I am not advocating that fixed assets containing only public 
information should be allowed to be stolen without regard to their intrinsic value; 
however, a stack of discs, each containing a large volume of technical information, 
may be a cheaper way to distribute advertising than large piles of paper. 



2 Risks 

The assessment of risks starts with the theoretical and moves to the practical. A set 
of generalised risks ("what could go wrong") are examined in the context of the 
particular system. These generalised risks are based on the literature of risk analysis 
and are summarised below. However, this list is not in any way comprehensive; it is 
intended to contain the main human risks, but such natural risks as lightning, 
earthquakes, etc. must also be taken into account. 

There are a number of risk assessment packages on the market which incorporate 
both human and natural risks with some form of weighting. In using such tools a 
degree of caution is essential because the prejudices (and blind spots) of the package 
developer may well be included in the advice which is the output from the package. 
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The weighting of dangers within the package's mechanisms can be very subjective; 
there was an early version of a well-known package which had been written by a 
team which contained a very extreme campaigner against smoking and the advice it 
gave in every case was that all smokers, smoking materials, lighters, matches, 
cigarettes, etc. must be banned from the entire establishment if there was one 
computer printer in the building because of the danger of printed output accidentally 
catching fire. 

It is equally important to avoid the prejudices, or wishes, of the staff concerned. 
With some packages, the respondent (usually the Information Processing Manager) is 
asked to give the relative importance to the organisation of various security-relevant 
aspects of the operations; a manager who is convinced of the efficacy of a particular 
countermeasure (eg, encryption) may bias the result towards this answer (eg, by 
claiming that it is essential to allow public access to parts of the system). 



2.1 Are Hackers Important? 

Here again, the terminology is wrong; these should always be termed “intruders” 
(or, in most countries now, “criminals”) to emphasise the total unacceptability of their 
actions. Having said that: yes, any intrusion into the system has an easily seen (but 
not easily quantified) cost; the systems administrator will have to spend time 
ensuring that no damage was done to the data or programs in the system, whether 
deliberately or accidentally. This is clearly a task on which large amounts of time and 
effort can be expended without much gain in the assurance that no damage has been 
done. 



2.2 External Intruders? 

Whether or not a system will be attacked by would-be criminals external to the 
owning organisation depends on how the system is connected to the outside world. 

If 

the system is totally self-contained with no connections to other 
computers, 

and 

all connections within the system made by wholly dedicated direct cables, 

and 

all terminal devices are in areas to which unauthorised people do not have 
any access, 

then and only then 

is it safe from external criminals: only internal criminals can attack it. 

In most cases today systems are connected to the outside world by some form of 
network; in all such cases there will be attempts made to intrude into the system by 
unauthorised outsiders. Some of them will know which system they are attacking, 
others will not care what the system is but will attack it “because it is there”. 
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There are four main motivations for computer criminals, these are Curiosity, Theft, 
Fraud, and Damage. 

Curiosity is the motivation of the “fun” criminal who breaks into other 
organisations' systems “just to see if it is possible”. The self-justification used is that 
if the owners did not want criminals to get in, then they should have better defences. 
Usually, all that is done by such people is to leave a message saying that they have 
been in the system, and possibly to use it as a stepping stone to other systems. Any 
damage done will be claimed to be wholly accidental and the system administrator's 
fault for not keeping them out. Such protestations cannot be accepted. In the 
physical world, just because an criminal can open a locked door using their own tools 
and without a key does not mean that it is the house owner's fault if they get in. 

Theft is the motivation of the industrial spy. Sensitive data or expensive software 
may be copied from a system and used to the benefit of the criminal, or of their 
paymaster. Such criminals are especially careful to hide their intrusions and 
computer files can be copied without the process leaving any traces. 

Fraud is not usually specifically “computer crime” at all, though it is often 
characterised as such by the press. If an criminal discovers how to authorise an 
electronic transfer of funds and uses that knowledge to steal money, that is nothing 
more nor less than forgery. It makes no difference that the “ink” is electronic, the 
effect, and hence the crime, is exactly the same as forging a signature on a cheque. 

Damage is the aim and motivation of people with a real or imagined grudge 
against the organisation which owns (or is thought to own) the system. The grudge 
may be loss of a job, or rejection of ideas, or a political belief, or any one of an 
endless list. It may also be the case that the criminal is not the person bearing the 
grudge, but is only acting for some third party. 



2.3 Internal Intruders? 

This is not the contradiction in terms which it first appears; an internal intruder is 
someone who has a right to be on the system for some specified purpose(s) but 
pursues a course of action which is not within that competence. In all systems there 
will be attempts made to intrude into the system by authorised insiders. Some of 
them will know exactly which part of the system they are attacking, others will not 
care what part of the system it is but will attack it “because it is there”. 

There are three main motivations for internal computer criminals (for that IS what 
they are) which are Curiosity, Fraud, and Damage. 

Curiosity is the main motivation of the most internal criminals who break Into their 
own organisation's systems “just to see what is there”. The self-justification used is 
that if other users did not want their files to be read, then they should not have left 
them where they could be read. The advantage gained by reading (usually) one's 
superiors' or one's colleagues' files is often less important than the voyeuristic thrill of 
reading imagined secrets. The internal criminal will deny strenuously that they have 
any responsibility for any damage done; if anything has changed it will be claimed to 
the system administrator's fault for not keeping them out. Such protestations cannot 
be accepted for the reasons given above. 
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Fraud is no different for the internal criminal than for the external criminal 
described above. 

Damage is the aim and motivation of people with a real or imagined grudge 
against their own organisation. The grudge may be loss of a promotion, or rejection 
of ideas, or personal animosity against a particular colleague, or a political belief, or 
any one of an endless list. It may also be the case that the criminal is not the person 
bearing the grudge, but has been infiltrated into the organisation for the purpose by 
some third party. 

Theft of information is not usually a motivation of the internal criminal. Sensitive 
data or expensive software may usually be obtained much more easily by an 
employee through other means than going to all the trouble of breaking the security 
of the system. The easiest way is to become friendly with someone who has the 
necessary access and then to persuade them to part with the desired information. 



2.4 Are Spies Important? 

This is a difficult question to answer, even in specific real cases. Consider the 
famous “secret formula, known only to two people” for some well known branded 
products; does anyone seriously believe that it would not be possible for a competent 
analytical laboratory at a rival manufacturer to reverse engineer that (or any other) 
product? Nevertheless, it is a question which must be asked seriously and the answer 
depends on the specific characteristics of the organisation concerned. 

BUT, never accept the statement from the head of the organisation that the closest 
rivals “have been his friends for years and would not allow such a thing”. The head 
of the rival organisation might well not be willing to authorise industrial espionage, 
but no one in the middle management will ask for such approval before embarking on 
a course of action which will be self-justifying if it succeeds. 



2.5 Is Fraud Important? 

It is tempting to say that the answer to this is “Only if money matters to your 
organisation”. The electronic transfer of money is, of course a tempting target for the 
professional criminal, but subverted financial controls can also be a major source of 
income for criminals. Such controls are not always fiscal; it may be possible to 
profit from diverting goods (missing deliveries), or even people (missing 
appointments), from their intended destination by falsifying messages in a computer 
system. In extreme cases it may be possible to steal goods or kidnap people if their 
movements are detected from the messages in the system. 



2.6 Is Loss of Confidence in the System Important? 

This is often the greatest danger of all; if the staff and/or customers no longer 
believe the computer, then efficiency plummets. Worse than the effort wasted 
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“making sure the computer is right” is the general feeling that the organisation is 
slipshod in its activities and does not care enough to get even simple things right first 
time, every time. This will cause staff morale to drop and then the organisation really 
will become careless in its activities; this quickly leads to a vicious circle of ever- 
worsening performance. No organisation can long sustain such a situation. 



2.7 Is Embarrassment Important? 

If an organisation can be held up to ridicule by having its documents or actions 
revealed out of context, then there will be a loss of confidence among both the staff 
and the customers. The sort of disclosure envisaged is the selective leak of part of 
one document from a set of contingency plans; for example, a manufacturer may 
(quite properly) have contingency plans for the unexpected failure of a crucial source 
of supply. Such a document might start: 

ABC Ltd. DISASTER PLAN §17 

Condition Met: sudden total failure of widget supply from XYZ Ltd. 

Cause: Catastrophic failure in XYZ Ltd operation (bomb, bankruptcy, 
etc.) 

Timing: At any time without warning. 

Action: 

This might well be reported to, and by, the more sensationalist sections of the press 
as: 



ABC Ltd plan for bankruptcy of XYZ Ltd. 

It has come to our attention that ABC Ltd have plans in place for 
immediate action after the bankrupting of XYZ Ltd which ABC believe 
could happen “at anytime”. 

Furthermore, every word of the article is true; the distortion is because of the out- 
of-context quotation and it is easy to imagine the effect this could have on the 
business relationship between ABC and XYZ. 



3 Threats 

Having decided on the specific risks then the threats (how the risks could be 
realised in practice) are assessed. This is where risk assessment tools come in to their 
own; they should be carefully selected to fit the situation and separate tools may need 
to be used in different environments. For a multi-national organisation different 
countries may well have different tools because of the different conditions, laws, etc. 
which apply (eg, a Belgian package may well not include earthquakes as a high risk, 
whereas a Japanese package ...). 
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Setting out to assess risks from first principles within the organisation is, itself, a 
risky business; the probability of missing some important security factor is too high 
for most organisations to contemplate. For this reason, if for no other, the use of a 
package prepared by specialists and incorporating the experiences of many 
organisations over a number of years has obvious advantages. 



4 Countermeasures 



4.1 How Are Countermeasures Selected? 

Having decided on the specific threats then the marketplace can be examined and 
specific countermeasures can be selected; indeed, many of the risk assessment 
packages suggest (or recommend) the possible counter-measures. A word of warning 
here is that a proprietary risk assessment package from a supplier of software or 
hardware could have as its output a list of that supplier's products only. The 
organisation should make sure that the output explains the risk envisaged and 
recommends the most cost-effective way of countering it. There may be a risk of 
passers-by on a public street looking in through the windows and reading sensitive 
information direct from the screens within; it may be cheaper to site the terminals on 
another floor, in other rooms, or facing the other way, rather than to fit expensive 
one-way glass in the windows (which the package supplier just happens to sell). 

There will always be some degree of mismatch between the countermeasures on 
offer and the risks identified in the particular environment of the system. A matrix of 
risks perceived in the system against risks addressed by the selected countermeasures 
will show where there is overlap (and, perhaps, overkill) and where there are gaps. 

The gaps left by the countermeasures are collectively known as residual risk. It is 
important to understand that in any system there is an element of residual risk which 
must be accepted by the organisation. A little thought will show that the security of a 
system can never be 100%. There will always be some small risk that information 
will leak (if only via subverted staff) or be corrupted (if only through mistakes made 
by careless staff). 

The obvious parallel in non-computer terms is to be found by considering the risk 
of fire; we design and build our premises to minimise the risk of the occurrence and 
spreading of fire (eg, fire-resistant furniture, fire-retarding doors, etc.), and then 
protect against the residual risk by installing fire-extinguishers, sprinkler systems and 
the like. Nevertheless, when the risk has been reduced as far as is reasonably 
possible, we still acknowledge the existence of the last little (but quantifiable) 
possibility of a fire by taking out insurance against it. 

When the countermeasures overlap, and two different countermeasures address the 
same problem, it is important to ensure that they work synergistically to enhance 
security and do not invalidate each other. The technique of multiple safeguards can 
be very helpful, as exemplified by supporting one’s trousers with both belt and 
braces, either of which could do the job in the event of the other failing. 
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Unfortunately, it is also possible to create exploitable vulnerabilities in a system 
where two different countermeasures do not work well together. 



4.2 How Are Countermeasures Installed? 

The installation of security in corporate computer systems is a difficult operation. 
Depending on the countermeasures selected, it may he necessary to close the systems 
down to ensure simultaneous implementation throughout the organisation. It is no 
use installing facilities for the automatic encryption of messages at only one end of a 
link! It may also he necessary to run a series of one-off conversion functions to 
change existing files, etc. to match the new facilities. It is no use attaching privacy 
labels to new files if existing files do not have a compatible labelling format. 

Since the necessary activities have a potential for causing some disruption to the 
systems, it is necessary for the change-over to be well planned, tested on a simulated 
system, and enforced by the highest levels of management in the organisation. If 
enforcement is not done then some small department will find sufficient (in their own 
view) justification for not cooperating with the change; this can cause, at best, 
difficulties in including them in the system or, at worst, a security hole which can 
never be filled. 



4.3 How Are Countermeasures Enforced? 

The policies of the organisation (such as obeying the legal requirements of 
accounting, health, safety, manufacturing, etc.) are enforced by various groups in the 
organisation performing audits. These may be the internal or external financial 
auditors, the internal or external safety authorities, the quality assurance staff and 
many others. Security matters are no different, in that it is necessary to have audits 
performed at unpredictable intervals by suitably qualified staff. These staff may be 
part of the security department, or internal audit, or QA; such details are unimportant 
compared with the need for such individuals to be suitably trained and qualified. 
There is little point in asking whether a user is applying the security policy if the 
auditors are incapable of checking the answer from their own skills. 

The reporting structure for such audits must be to a sufficiently high level in the 
organisation that no department head can arrange for that department’s security to 
remain unchecked, or deficiencies uncorrected. 

A corollary of such audits is the need for regular review and updating of policy, 
taking account of any new factors in the organisation’s structure or environment (eg 
mergers, relocations, decentralisation of processing etc). This review requires 
management effort to be expended on real monitoring with positive review and 
follow up of the audits and the auditors themselves. It is necessary to recognise the 
high speed of communications worldwide via the Internet and the potential size of the 
audience; if someone spots a weakness in a system the bulletin boards patronised by 
computer criminals will ensure that the news spreads very quickly. li is important to 
use extreme care in reviewing what is published on a web page and in determining 
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the effect of changes as time passes. Any risk of worming back through the 
underlying web host and changing the truth must be countered. 



5 Conclusions 

It should now be apparent that any attempt to add a pinch of security to the system 
which is instigated by staff at a low level of the hierarchy will not succeed. The 
initial impetus must come from the top of the organisation. Furthermore, the 
implementation of security within an organisation is like any other project: the more 
effort goes into planning and designing it, the more effective, and cost-effective, the 
final outcome will be. 
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Abstract. The nineties set off the ’’information age”. Companies, or- 
ganisations, the whole society have become utterly dependent on comput- 
ers for their proper functioning. Since information gathering, processing 
and distributing have become so important, it should be treasured as 
a strategic asset, and therefore, properly protected. In this paper, we 
first focus on the security policy. Then we examine the major threats 
that may compromise the security of information systems. Finally, we 
present an overview of security measures is presented. 



1 Introduction 

The nineties set off the ’’information age”. Companies, organisations, the whole 
society have become utterly dependent on computers for their proper function- 
ing. However, although the efficiency has improved rapidly, in many organisa- 
tions, the condition of computer security has never been so poor. Actually, it is 
worsening, and this for several reasons. 

— During the last decade, the information technology has evolved very fast. 
Security was not an issue in the beginning, and has never been able to keep 
pace. 

— At first, computers were used in invoicing and wages administration. Later 
on, they were involved in stock management, EDI, . . . Nowadays, they are a 
necessary tool for strategic decisions. 

— Networking is booming. The central mainframe has been replaced by a LAN 
of PCs or workstations. Because of the pressure of the market, these LANs 
are connected to the Internet or the public telephone network. 

— The democratization of information technology moved the computers out of 
the computing centre into the work place. 

One aspect of democratization, the lowering of thresholds, needs some 
elaboration. Although security incidents are often (wrongly) associated with 
break-ins by hackers or criminal organisations, most incidents are caused by 
insiders (employees of the organization, maintenance people, ...). (See also 
tab. D) This is not surprising, since insiders have less hurdles to take and pos- 
sess inside information. Moreover, a computerized office is an attractive target 
for fraud: 
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— there is very little exposure; if well prepared, a security breach takes less 
than a second; 

— controls -if present- are performed by computers, not by people; 

— most information is centralized and available from the PC in the office; 

— the fraud can be repeated over and over again; one does not have to be 
greedy: ten thousand times one hundred equals one million, and will probably 
be less detectable; 

— the fraud can be automated, without any human intervention 

Beside incidents caused willfully by insiders, there are three other classes of 
incidents. See tab. [D 



Table 1. Frequency of Security Incidents 



Frequency 


Reason 


50-60% 


Errors 

due to inexperience, non-chalance, panic reaction, . . . 


15-20% 


Insiders 

i.e. (former) employees, maintenance people, . . . 


10-15% 


Disasters 

such as flooding, lightning stroke, fire, . . . 


3-5% 


Outsiders 

i.e. hobbyist, hackers’ club, competitor, organised crime 
(foreign) intelligence agency, . . . 



The high percentage of errors that constitute a security breach, stems from 
the fact that more unexperienced users are working with computers; some of 
them can barely type or lack any iT-knowledge. These unexperienced users can 
be very harmful if the system itself is not sufficiently protected. Also, users 
can panic when confronted with a break-in, thereby aggravating the security 
breach, instead of stopping it. Finally, by moving computers into the work place, 
accidents will happen more frequently: a server-machine in the office may seem 
an ideal place for a plant; however, plants need watering, and few servers will 
survive spilt water. 

Disasters are fire, flooding, explosions, lightning strokes, storm, but also 
major hardware failures, etc. These are hardly or not at all accounted for. Many 
companies will not even survive a situation where most of the iT-infrastructure is 
destroyed, because there is no backup-site that can take over the data processing. 

Outsiders range from the computer hobbyist, who gets a kick from breaking 
into other computers, to competitors who are interested in your secret research 
results or in your sale’s strategy (industrial espionage), to national or foreign 
intelligence agencies. However, one can expect an increasing amount of break-ins 
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caused by criminal organisations (the mob) who will try to subvert the computing 
infrastructure in order to bribe the company later or because they have been 
hired by the competition. 

2 Security Policy 

Vast amounts of resources are being spent on ’’securing” the computer infras- 
tructure. Every time a major security breach appears on the front page, some 
countermeasures are hastily installed. One can hardly expect any security with- 
out a policy. Every organisation should spend enough time and resources on 
defining a security policy and on implementing the necessary measures. 

The security policy should at least treat the following topics: 

— the general objective; this serves as the justification of the policy; 

— the importance of information technology for the organization; 

— the limited validity of the policy; it should be short term; this ensures that 
the policy will be reviewed and adapted every year or two; 

— the allocation of sufficient resources (budget and personnel); 

— the specific objectives, requirements and responsibilities. 

The implementation of a security policy will only succeed if the policy is endorsed 
by top management. 

2.1 Information Quality 

In an organization, there are several information flows; some are more valuable 
than others. They can be characterized by the following quality labels: 

— Some information is confidential. For instance research results should be 
kept secret for the competition, but also the law enforces the protection of 
the privacy of the individual. 

— Integrity deals with the reliability of the information. This means that the 
information is correct and authentic. In a network environment, this means 
that the information has not been tampered with, and is no replay of a 
previous communication. Some applications (e.g. electronic commerce) will 
even require that sender, (or receiver) cannot repudiate the date sent (or 
received) . 

— Information should be available when needed. Although often overlooked, 
availability also involves the timely processing and distribution of the in- 
formation. Denial of service attacks, which are in general very difficult to 
counter, can jeopardize the continuity of the processing and hence, the sur- 
vival of the organization. 

In order to qualify the information, the users of the computer infrastructure 
should be interrogated. Questions to be answered include: 

1. Questions concerning the confidentiality: 

— ’’What are the consequences (financial, legal, . . . ) if this information falls 
into the wrong hands (colleague, competitor, press, . . . )? 
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“ ’’Who will benefit from this information? (competition, press, foreign 
intelligence agency, . . . )” 

2. Questions concerning the integrity: 

— ’’What happens when the data is erroneous, incomplete or obsolete?” 

— ’’What will happen if information is lost, replayed, or delayed?” 

— ’’What errors can be introduced deliberately?” 

— ’’What are the weakest issues?” 

— ’’Who will benefit from these errors?” 

3. Questions concerning the availability: 

— ”How IT-dependent is the unit?” 

— ’’What are the time-critical aspects?” 

— ’’What is the expected response time?” 

— ’’What are the implications (financial, legal, ...) if the system breaks 
down for . . . hours/days?” 

— ’’When are most queries/processing done?” 



2.2 Risk Analysis 

When the security policy has been formulated, it should be implemented. The 
policy itself specifies what should be protected, but does not impose any mea- 
sures. Before any security plan is drawn up, one needs to know what are the most 
likely security breaches to occur, and what implications are involved. Usually, 
this is determined through risk analysis. (See also fig. Cl) 

The inputs for the risk analysis process are: 

— the security policy, 

— the possible adversaries (insiders, competitors, press, . . . ) 

— the known weaknesses of the IT-infrastructure, 

— possible threats. 



Table 2. Losses should be all-inclusive 





Direct losses 


Indirect losses 


Material losses 


wages 

overtime 


overdue payment 


Immaterial losses 


frustration 


negative publicity 
loss of goodwill 



For each threat, the probability of occurrence is determined (often, one has 
to rely on an educated guess). Then the implications of the threat are examined: 
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Adversary 

Threats 



Losses 



Fig. 1. The Risk Analysis Cycle 



’’what are the potential losses if the threat happens?” The losses should not 
only include time and money spent to undo the effects of the threat, but also 
financial and legal implications of a possible lawsuit, the effects of a bad press, 
loss of goodwill, etc. (see also tab. 0. Finally, the risk is calculated according 
to the following equation: 

Risk = Probability x Loss 

Figure ^ shows that several iterations will be necessary before a conclusion 
can be drawn. Also, it might be necessary to adapt the security policy. The 
threats with highest risk should be countered first. A set of appropriate measures 
will be assembled. These measures will be a mixture of physical protection 
and technical measures, and procedural measures. Obviously, the proposed 
measures should not cost more than the threat they counter. See also sec.El 

The risk-analysis should be reconducted every time the policy changes or a 
major security incident occurs. Probabilities and risks should be revised. 

2.3 Security versus User-Friendliness 

There is no system that is 100% safe, except one that is switched off and kept 
in a bunker. Many security measures make the system less user-friendly. If the 
users are not convinced of the usefulness of the measure, they will subvert it, 
one way or the other. Humans are often the weakest link. Through continuous 
education, the users are kept vigilant and aware of their responsibility towards 
the overall security. 
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3 Threats 

In this section, the malicious security incidents are classified, and some measures 
are presented. 

Table Olgives a ta,yonomv[l()j of the major threats. The left column indicates 
the typical steps and modes of intended use of computer systems. The right 
column involves misuse. 



Table 3. Taxonomy of security threats 



normal intended use 


misuse 


access to the computer system 


external misuse 


use of the computer system 


hardware misuse 


apparently authorized use 


masquerading 


direct use 


pest programs for deferred misuse 


use apparently conforming 
with intended controls 


bypass of intended controls 


active use 


active misuse of resources 


apparently normal use 


passive misuse of resources 


apparently proper use 


misuse resulting from inaction 


proper use 


use as an aid to other misuse 



3.1 External Misuses 

External misuse refers to threats that do not require physical access to the 
computer system or network. It is not difficult to look over one’s shoulder and 
observe the keystrokes (for instance, when the password is being entered). How 
often have users posted their account-numbers and passwords on their terminal? 
The contents of a computer screen can be copied from a distance (e.g. in a van 
parked outside the building) through a device that can capture and visualize the 
electro-magnetic radiation of the screen. These examples can be summarized as 
visual spying. 

Other threats in this class include deceiving users and operators, also called 
social engineering. Unexperienced users can easily be tricked into performing 
foolish actions: a forged phone call or forged e-mail messages (supposedly coming 
from the system operator) mentioning a major break-in, and asking the recipient 
to change his password into a specific word; see figure El 

Operators are often willing to respond to a phone call from a user who has 
forgotten his password without any verification of the identity of the caller. Also, 
they give the superuser-password over the phone to someone who mispresents 
himself as a maintenance person, etc. 

Finally, searching waste baskets for printouts will often give an attacker a 
wealth of information that can be used in further attacks. 
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From: root 
Subject: ALERT!!! 

Dear user, 

Dur site is being attacked by a malicious group. 
THEREFORE, CHANGE YOUR PASSWORD IMMEDIATELY INTO THE WORD 
STOP-IT 

UNTIL FURTHER NOTICE. 

I hope we can stop the attack as soon as possible. 

I’ll keep you informed ... 



Your System Administrator. 



Fig. 2. Forged e-mail can trick users into doing foolish actions 



3.2 Hardware Misuse 

It is often forgotten to erase disks, tapes, cassettes, . . . , before they are dis- 
carded. The erasure should be done thoroughly by overwriting these media with 
innocuous data. 

Eavesdropping on communication lines is not very difficult, especially on 
LANs, which are mostly broadcast media. Several public domain network sniffers 
are available. Some of them can be configured to show only the first hundred 
bytes of a telnet (ftp, . . . ) session. Since passwords are sent in cleartext, such a 
sniffer can capture quite a few account-password pairs in a very short time. 

Electronic jamming can cause serious interference on the network, and initiate 
a denial of service attack. Furthermore, disgruntled employees may damage or 
modify the equipment; if the power supply or cooling is interrupted or sabotaged, 
the iT-infrastructure comes to a grinding halt. 

Finally, since most computers and storage media are small, they are easily 
removable. Theft might become a serious problem, if the physical access to the 
building is not strictly controlled. 



3.3 Masquerading 

Once passwords or other authentication means have been captured, they can be 
used to masquerade as somebody else. Seizing passwords is not that difficult. 
Humans are known to pick bad passwords; several studies have shown that 25% 
of the passwords can be guessed easily P|. Moreover, passwords can also be de- 
tected through visual spying or social engineering (sec. 13. Ill , eavesdropping on 
the network Isec. I3.2ll . installing login-spoofs (sec. [I.4ll or conducting a dictio- 
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nary attack (sec. [3. till . Finally, most systems come with pre-installed universal 
accounts that are protected with the same password! 

In piggy-backing attacks, the attacker gains physical access to communication 
lines or workstations. Unattended logged-in terminals, with unlocked keyboards, 
are also a prime target. Commands entered (or inserted in the communication 
stream) will be executed on behalf of the logged-in user. 

Playback attacks merely repeat captured conversations or messages. 

In a world- wide network environment, attacks may be very difficult to trace 
to the originator, if the latter is clever enough to use many different systems: his 
physical whereabouts will be completely masked. This kind of attack is some- 
times called network weaving. 

Computers linked by LANs typically use trust to enhance the user-friendliness. 
That way, users are only required to authenticate to one of the trusted machines. 
From then on, they can access any resource on any other machine without any 
further authentication. Spoofing attacks try to exploit this trust. If the attacker 
succeeds in making a server-machine believe the request came from a trusted 
host, the server will act upon the request. 

One of the latest examples of masquerading, is Web spoofing it allows 
an attacker to create a ’’shadow copy” of the entire World Wide Web. Accesses 
to the shadow Web are funnelled through the attacker’s machine, allowing the 
attacker to monitor all of the victim’s activities including any passwords or 
account numbers the victim enters. Moreover, the attacker can send misleading 
or modified data to Web servers in the victim’s name, or to the victim in the 
name of any Web server. See also fig. 0 



3.4 Pest Programs 

By installing pest programs, the attacker tries to set up opportunities for 
further misuse. Table El gives short overview of the different kinds of malicious 
software. 

A Trojan horse is a program that does something unexpected. For instance, 
it clandestinely copies data, it reformats the disk, it disables the system, etc. If 



Table 4. Pest Programs 



Type 


Explanation 


Trojan Horse 


Program that does something unexpected 
(and often secretly) 


Mule (Spoof) 


Program that mimics another program 


Rabbit 


Program that overloads a system 


Worm 


Program that replicates itself through the 
network 


Virus 


Program fragment that, when executed, 
attaches itself to other programs 
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victim’s 
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request spoof URL 

^1 

spoofed page contents 

"" 5 



4 

modify 

page 



WWW . attacker . org 




Fig. 3. Web Spoofing: An Example Web Transaction 



the unexpected behaviour manifests itself only when a certain condition (date) 
is met (reached), the program is said to contain a logic (time) bomb. There are 
many cases known where a system administrator replaced a program by a Trojan 
horse, that tested the presence of the administrator’s name in the password file. 
If the name disappeared, the program did something harmful. 

It can be proved that there exist no algorithm that can decide whether a program 
is Trojan or not. Moreover, it is not sufficient to scrutinize the source code of 
a program, since a Trojan compiler may have inserted Trojan instructions in 
compiled program. 

A mule is a program that mimics another program, but does something 
completely different. The classic example is a login-spoof, that behaves like the 
login-program (i.e. it reads an account name and password), and then prints an 
error message saying "login incorrect". The account name and password are 
mailed to the attacker. 

Rabbits are programs that continuously fork new processes. Hence, the sys- 
tem gets overloaded, and will eventually be completely locked or crash. This is 
a special case of a denial of service attack. 

A worm is a program that replicates itself through the network. The pro- 
gram may be malicious or it may be used constructively to provide extensive 
multiprocessing . 

Viruses replicate themselves by attaching their code to other programs. 
An infected program becomes a Trojan horse, since when it is executed, it will 
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try to infect other programs, and possibly do something harmful. A virus does 
not necessarily consist of machine-executable code. Many programs (such as 
spreadsheets, word processors) can execute macros included in their documents. 
Since these macro-languages allow for reading and writing files, an infectious 
macro is easily developed, and inserted in a document. MimeQ is great to send 
infected documents to the whole world! 

The setting up of pest programs may employ other misuses. An insider may 
easily install such a program (possibly unknowingly). Although most systems 
provide some sort of access control to their resources, this limited access does 
not prevent the spreading of malicious software. For instance, if the system ad- 
ministrator executes an infected program (e.g. game), he will first infect his own 
programs. Later on, when the administrator executes one of his (now infected) 
programs with super-user privileges, he will infect the whole system. See fig. El 
the small box inside each file represents the viral code. 
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Fig. 4. The proliferation of a virus 



3.5 Bypass- Attacks 

By using existing flaws in programs, authentication can be avoided. 

A trapdoor is an entry path that is not normally expected to be used. In 
a few cases, it was implemented for debugging purposes, and afterwards com- 
pletely forgotten. E.g. the sendmail-program hid a DEBUG command, which was 
exploited by the Internet worm PH- 

^ Multipurpose Internet Mail Extensions. 
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Some trapdoors are software bugs. There are plenty examples: the finger- 
daemon (exploited by the same worm), the talk daemon, etc. Many servers do 
not check their inputs. An attacker can send ‘unexpected’ data (e.g. of the wrong 
format or oversized) or execute the server-program in a specially made environ- 
ment (e.g. with different ‘space’-characters, or different dynamically linkable 
libraries, . . . ) . The oversized data will provoke an overflow of the buffer, which 
is allocated on the stack. Hence the stack will become garbled (important book- 
keeping information, such as the return addresses of the procedure calls, will be 
modified) . That way, the attacker can make the server-program do whatever he 
likes. See also fig. 
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Fig. 5. Buffer overflow may cause malicious code to be executed 



3.6 Active Misuse 

When the attacker has access to the system with the proper privileges, he can 
change the state of the system or modify data. Any kind of malicious actions 
for which the attacker has enough authority can be performed, such as: creating 
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or deleting data, denying or delaying service to other users, entering false or 
misleading data. 

A special form of active misuse is the so called salami attack, in which numer- 
ous small pieces (e.g. a few befs on every transaction), are collected for personal 
or corporate gain. 

Denial of service is one of the most difficult attacks to deal with. Usually, the 
attacker tries to saturate a communication line or a server (by sending millions 
of packets) or tries to exhaust a resource (e.g. by sending thousands of huge 
e-mail messages, that fill the local disk). 



3.7 Passive Misuse 

Passive misuse involves reading information with apparent proper authorization. 
It is clear that confidential information can fall into the wrong hands. 

In this stage, the attacker hunts for interesting data through random brows- 
ing or selective searching. The curiosity of humans is often so strong, that bait 
system^ can lure a computer cracker long enough for the operator to trace the 
felon. 

Some databases do not answer queries that pertain to one specific case or 
person. However, by selecting the right set of queries, it is often possible to infer 
the wanted information. Also, traffic analysis of possibly encrypted conversations 
can often reveal interesting information. 

Finally, covert channels can be used to subvert a system that disables the 
flow of information from a privileged user to an unprivileged user. For instance, 
one bit of information can be signalled to an unprivileged user on the basis of 
whether or not a shared resource (e.g. disk) is exhausted or not. 



3.8 Inactive Misuse 

Inactive misuse is a typical incident where an insider does not perform a task 
for which he/she is in charge. Some examples: 

— the backup is not or only partially taken, 

— the account of a former employee is not removed, 

— accounts that come pre-installed on a system, are not disabled, 

— old disks, tapes, cassettes are not erased before being disposed of, 

— the logs are not checked regularly, 

— a terminal, on which a user is logged in, is left unattended, while the keyboard 
is unlocked. 



A bait system is a computer that contains fake top-secret information. 



2 
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3.9 Indirect Misuse 

Indirect misuse relates to all actions that are performed for later misuse. Some 
typical examples include: 

^ pre-encrypting of data (in order to be able to break a ciphertext), 

— dictionary attack on a captured password file, 

— scanning telephone numbers of computers by using an autodialler. 



Dictionary 

wordl 

word2 

words 

Idots 




Password file 

H(passwordl) 

H(password2) 

H(password3) 

H(password4) 

Idots 



Fig. 6. The dictionary attack 



In a dictionary attack, one attempts to identify which dictionary words are 
used as passwords. Usually, passwords are not stored in readable form in the 
password file, but are transformed through a one-way function. It is not difficult 
to apply the same function to every word of the dictionary and compare it with all 
the values found in the password file (see fig.lOj). The same attack is also possible 
in all situations where passwords are used as cryptographic key, as long as the 
encrypted plaintext is recognizable (e.g. contains readable text, a timestamp, 
a network address, . . . ) . For instance, in the Kerberos authentication system 
|9I4| . the ticket granting ticket (tgt) is sent to the user encrypted with a key 
derived from a password. Since the tgt contains ip-numbers, it is susceptible to 
a dictionary attack. 
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4 Measures 

It is difficult to give a complete overview of measures that can be taken. Of- 
ten, one measure will not suffice to counter a threat. On the other hand, some 
measures have an impact on many threats. 

Security measures will in general reduce the probability that certain threats 
occur, and/or limit the possible losses. They can be preventive, detective or 
corrective. Also, losses can be insured with an insurance company. 

The measures can be categorized in three different classes: 

— physical protection, 

— technical (logical) measures, 

— organizational procedures. 

Table gives an brief overview of the different kinds of measures. The fol- 
lowing subsections illustrate the different classes. 



Table 5. Classification of Measures 





Physical 

Protection 


Technical 

Measures 


Organizational 

Measures 


Preventive 


guard at entrance 


firewalls 


education / training 


Detective 


motion detector 


Logs 


call-back procedure 


Corrective 


UPS 


anti-virus monitor 


backup 



4.1 Physical Protection 

Physical protection deals with the physical access to buildings, hardware and 
media: 

protection of the building 

measures against natural disasters, assaults, unwanted visitors, . . . 

— protection of the hardware 

measures against theft, vandalism, sabotage; measures limiting physical ac- 
cess to certain rooms; provision of spare parts (computers, . . . ) and backup- 
site, etc. 

— protection of the data (media) 

measures for the protection of removable media (disks, tapes, CD-roms, . . . ), 
and — often forgotten — the backup media, etc. 
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protection of the utilities 

measures for the protection of power supply through and for the pro- 

tection of communication channels, etc. 



4.2 Technical Measures 

Technical (or logical) measures are usually software solutions (or a combination 
of hard- and software) : 

— logical access control 

protects the internal resources, limits the user’s capabilities; 

— authenticated login-session 

protects the access to the system; it may involve cryptographic protocols, a 
call-back mechanisms, etc.; 

— logs 

can provide evidence for security incidents; 

— anti-virus programs 

scan files for known viruses, check the integrity of files, or alert when suspi- 
cious actions are about to be executed; 

— cryptography 

protects the confidentiality, the integrity and the authenticity of data and 
messages; an important aspect is the key management (see organizational 
measures, sec. l4.;ill : 

— firewalls 

filter packets and shield the internal network against certain hostile actions; 
they can also impose a strict route inside and outside the internal network. 



4.3 Organizational Measures 

Most measures will fail if no strict procedures are developed: 

account management 

includes specific rules for the creation/deletion of accounts, rules for well- 
chosen passwords, . . . 

automatic backup 

consists of a backup scheme, a restoration scheme, a number of safe vaults, 
etc. 

auditing, monitoring 

are important instruments in the detection of security breaches, and when 
applied properly can stop these incidents early. 

education/training 

has as main target keeping the users aware of the importance of the security 
measures and alert for symptoms of incidents, etc. 

® Uninteruptable Power Supply. 
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an incident plan 

involves a detailed (tested!) procedure, the appointment of a contact person, 
the elaboration of juridical steps, etc. 
key management 

determines how and when new keys are chosen, . . . 



5 Conclusions 

Computer security is more than implementing a few measures. It should be de- 
rived from an explicitly stated security policy. No system can be secured for 
100%. However, by selecting a good mixture of preventive, detective and correc- 
tive measures, the security incident rate can be drastically reduced. 

Resources spent on securing the iT-infrastructure, should not be considered 
as ‘unproductive overhead’. In fact a good security creates added value: 

~ it reduces the probability of fraud, 

~ it avoids hours of overtime, 

~ it increases the reliability of the services, 

— it may be the only guarantee for the survival of the organization. 
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